Both the Android and iOS SDKs are pretty specifically optimized for performance on their respective devices, and I don't see the need for those types of optimizations going away anytime soon. As an example, take a UITableView (iOS) or ListView (Android), backed by a SQLite data store that has returned 2000 rows to display.
It's not actually feasible (for performance & memory reasons) to simply render all 2000 rows and allow the user to scroll through them. Instead, both the UITableView & ListView recognize that on a phone, there's only really enough room to display 5-6 rows anyway. So they instantiate those 5-6 rows and populate them with the first few rows from the result set. Then, as the user scrolls down, additional rows can be loaded in, and the previously used rows (that have now been scrolled off-screen) get recycled to represent new rows at the bottom of the table view. Additionally, the data for each row can be loaded on-demand as the user scrolls the row into view, and then be freed once that row has scrolled off screen.
It's a nice and tidy optimization that is absolutely necessary on both platforms (failure to implement the recycling mechanism can basically kill your scrolling performance). That is just one example, there are many more optimizations developers make to keep their apps smooth and responsive on iOS/Android, and a lot of those optimizations involve relatively low-level interaction with the underlying GUI toolkit.
I don't think these types of optimizations are feasible when writing HTML+JS apps, they're simply abstracted too far away from the underlying GUI toolkit. (Some might even say that layer of abstraction is the entire point of using HTML+JS in the first place.) Regardless, I think it severely limits the scope of the types of apps you can create using HTML+JS.
And I haven't even mentioned games, or apps that do any sort of audio/image/video processing. (Even on the web these are often relegated to Flash.)