HTML5 vs. Obj-C is not the same as PHP vs. C
Brace yourselves, because I'm turning the old fuddy-duddy up to max for this post. Alternative linkbait titles for this post are "Why HTML5 mobile apps suck" and "Get off my lawn!"
When I started coding in PHP in 1996, the alternatives were Perl and C. It was generally regarded as "easier but slower" than both of these alternatives. At the time there was an argument from Perl and C coders that the sacrifices in efficiency weren't worth it for the ease of development: websites needed to render fast, and scale to what was then considered high traffic.
How PHP won
Today there appears to be a similar argument emerging about HTML5 compared to Objective-C apps for iPhone or Java for Android. And there is no question in my mind that HTML is the "easier but slower" option -- writing efficient, performant Objective-C requires knowledge of memory management, alien to programmers coming from web-centric languages (and Java), and the mere task of rendering something to the screen, a first-class operation in HTML, requires piles of boilerplate and usually a specialized IDE to get right in Obj-C.
Why HTML can't compete
Some people are pointing to the earlier victory of PHP and, more broadly, the triumph of web apps over desktop software as proof that HTML is bound to triumph over native languages. But there is a crucial difference between the older PHP vs C contest and the one now ongoing between HTML and Objective-C, and it's the end-user experience. A website written in PHP (or for that matter Python, Perl or any other scripting language) is, once rendered, indistinguishable from one rendered in C. The buttons, rendered client-side, click equally fast, pages scroll at the same speed. Your only performance hit is at render time, and caching can take care of much of the difference, which even 15 years ago when the first battle was being fought was only the matter of a handful of seconds.
This is a nontrivial difference that does and should affect your choice of development platform. It doesn't matter if you can develop your app faster: if it is a noticeably poorer experience for the user, somebody who spends more time building a better product simply by replicating all your features in Objective-C will eventually steal your users. Simply put, Objective-C makes better apps than HTML can.
...at least, not yet
Right now, a highly-optimized HTML app can out-perform a badly written Obj-C app, but your scope for optimizing an Obj-C app is so much greater that there's ultimately no contest. My friends who are professional iOS developers speak of shaving tens of milliseconds off render time; an HTML developer cannot go any faster than the maximum speed of Webkit, and while it's a triumph of mobile engineering, it's still nowhere close to native UI in rendering speed.
Smart people like Andrew Betts of the FT think optimizing your HTML app makes more business sense than focusing on a multiple platforms: it's more future-proof, it avoids platform fragmentation across iOS/Android/whatever-Microsoft's-mobile-platform-is-called-this-week. Each bit of optimization happens across all platforms, goes the thinking, so it's more bang for your buck. And eventually mobile platforms will catch up... right?
In the PHP vs. C debate, the ultimate decider was Moore's law: computers got faster, and memory got cheaper, faster than apps grew in complexity, and now the performance difference between PHP and C is negligible simply because both numbers are so small -- the majority of rendering time is now client-side, a sea-change that happened so slowly that it took developers years to notice they were spending time optimizing the wrong things.
Place your bets
The question for you as a developer right now is: in the lifetime of my app, is Moore's law going to take care of the performance hit I accept by using HTML? Is the benefit of launching on the big three platforms simultaneously great enough to justify a less-than-optimal user experience?
If you're, say, the Financial Times, you're not going anywhere. It makes sense to place a long bet on HTML. But if you're a startup, you're probably thinking in terms of months. I will bet that Moore's law is not going to take care of your performance problems inside of the next two years. If in that time a competitor can take 3 months and produce a better user-experience than you could in 4 weeks with HTML, your two-month head start is probably not going to be enough.
Bottom line: if you're a startup looking to exit prior to 2015, you should probably still be writing your apps in objective-C.
P.S. Entirely coincidentally, it seems Facebook agrees with me, and have rewritten their app in objective-C.
 Depending how long you've been a coder, it may or may not come as a surprise to you that PHP, now fast and (depending on your framework) lightweight, was once the slowpoke, resource-hog language.
 Unlike iOS and Obj-C, I have little experience using Android and none at all in developing for it. I believe the same arguments generally apply, but don't hold me to that.
 No offense intended to BlackBerry developers, but I think it's uncontroversial to assume RIM isn't going to be a force in the mobile space two years from now.