Matt Gemmell explains one major reason why native apps have an edge on web apps:
The calculator web app is running in the frontmost tab of a web browser app, which in turn is running on a smartphone. The device’s screen is no longer task-dedicated, but instead is conceptually split into the “content” (in this case, our task-specific web app), and the “chrome” – the actual interface of the web browser. The browser has an address bar, a search field, navigation and bookmarking controls, tab-switching UI and more – none of which has any meaningful or intrinsic relationship to the actual calculator we’re using.
A web app (frame 1) running within a browser app (frame 2) on a smartphone device (frame 3) has three frames of interaction. You’re reaching through a window, then putting your hands into a box, to perform your task.
Chrome has a cost. The more interface you have visible, the higher the cognitive load on the user. When parts of that interface belong to entirely different, unrelated frames (or levels) of interaction, the load is high.
Also, about why it matters:
Many of the arguments I’ve seen that are pro-web tend to be technological arguments, and they’re maybe mostly true as far as they go. But consumers don’t buy based on quickness of updates, newness of technology, or whether their vendor is “in control” of the development process. Platform-agnosticism is part of your politics, not your customers’ buying decision. Users couldn’t care less, particularly non-technical users.