All of these arguments are the same arguments you need to think through when determining whether to make a web app vs. a native app on the desktop. They're identical, because the desktop is just another device.
I completely agree with all the arguments, except possibly that we should never use hacks. We used (and still use) hacks on the web for desktop use when browsers sucked, and we'll do it on mobile devices, too. It's the way the state-of-the-art is pushed forward; it's inevitable. I think he would agree with me, seeing that he pointed out Scrollability's use on the iPad being somewhat valid. That said, the author's underlying point examines why we use those hacks and to evaluate whether we're solving a non-existent problem.
Edit: I might clarify my hacks point. The reason they're inevitable is that they sometimes expose browser deficiencies. A current example would be web sockets. We've been using comet-type hacks in lieu of a real web socket solution (and Chrome has now implemented one).
I would actually argue that the web browser is not the correct place for web applications on mobile devices. "What?", I hear you say. I would go to the extra step of requiring the user to instal the app on their home screen, where the browser chrome is not visible. This way, the user is not confused with the back button problem, or the URL bar getting in the way of them using my app. An app is designed to be launched from the home screen, not the web browser which is designed for viewing web pages. The reason I almost never use mobile web apps is because they are too hard to launch compared to their native equivalents. I have to go to my web browser, type in a URL or choose a bookmark, hope I typed it right, wait for it to load from the server, etc. The competing native app or "installed web app" launches almost instantly with one tap on my home screen. Home screen web apps still have all the benefits of web applications, but they avoid some of the problems and feel more "app-like", or more like what the user is used to. This also allows us to create a more native looking and feeling interface that the user will have an easier time using because it is similar to what he knows.
I'm actually not even sure if the mobile web is ready for full-featured applications at all yet. The huge platform differences really make it a challenge to produce a good user interface across all of them. Mac, Windows, and Linux are similar enough to make it possible on the desktop, but the mobile user interfaces have not come together enough yet to make it possible on mobile. I think the current options are either to create native apps for each device or to create a web app with differing UIs according to the platform you are on in order to create the best user experience. I know a lot of people with disagree with me, and even I'm not entirely sure about this position, so convince me otherwise! :-)
I agree with most of what you're saying. Add To Homescreen is a great feature for regular users of a mobile web app. Your application needs to support both modes however (browser-mode, and app-mode). The easy answer is to say: "Use back button in browser, and use navigation bar in app-mode" - Which is certainly possible from a technical perspective, but jarring from a UX perspective. You have to essentially re-learn how to use the application when you click that button. Not only that, but if you add a navigation bar in app-mode, then your navigation is on the top (where it would've been on the bottom in browser mode), and that has other fallout in relation to other elements that you may have placed on the top of the page in browser-mode.
I don't think the app needs to support both modes. When you go in a browser, it should just say, click here to install the app to your home screen. That's the easy answer, IMO.
But then you're increasing the barrier to entry to users. You're assuming the user cares enough about your app that they will sacrifice a spot on their home screen and will want to tap three buttons to get to it...
I completely agree with all the arguments, except possibly that we should never use hacks. We used (and still use) hacks on the web for desktop use when browsers sucked, and we'll do it on mobile devices, too. It's the way the state-of-the-art is pushed forward; it's inevitable. I think he would agree with me, seeing that he pointed out Scrollability's use on the iPad being somewhat valid. That said, the author's underlying point examines why we use those hacks and to evaluate whether we're solving a non-existent problem.
Edit: I might clarify my hacks point. The reason they're inevitable is that they sometimes expose browser deficiencies. A current example would be web sockets. We've been using comet-type hacks in lieu of a real web socket solution (and Chrome has now implemented one).