Autant la prolifération des applications dédiées à un seul fournisseur de service me semblent une mauvaise chose, (par exemple une appli sncf, une appli idtgv, une appli easyjet, une appli airfrance, etc.) pour les raisons énoncées dans l'article, autant tout remplacer par du web n'est pas forcément le mieux, mais pour d'autres raisons que je vais exposer.

Si les sites web deviennent aussi riches que des applications, et utilisent un tas de fonctionnalité comme la géoloc, les gyroscopes, l'appareil photo, le stockage sur la mémoire locale, l'accès aux contacts, etc., alors au lieu d'API au niveau de l'OS, tout sera implémenté dans le navigateur, qui sera lui même au dessus de l'OS. Le navigateur ne sera qu'un proxy qui réimplementera son propre OS au dessus de l'OS normal (android, ios), et qui aura ses propres failles de sécurité en plus de celles de l'OS. Ce n'est rien d'autres qu'empiler des couches, chacune ayant sa complexité et sa lourdeur.

L'avantage actuel qu'apporte le navigateur c'est une standardisation de l'API (W3C) alors que comme vous le dites, les applications natives n'ont pas de standard. Pourtant, qu'est ce qui empêcherait de définir une API système standard entre OS, mais laissant libre chaque plateforme sur le reste (ios pourrait continuer à utiliser objc et android java) ?

Aussi, des applications dédiées à une tâche, et non à un fournisseur, devraient voir le jour. Une application de réservation, qui ne serait pas dédiée à sncf, ni à idtgv, ni à airfrance, etc., mais qui agrégerait leurs données (on pourrait choisir quelles sources on veut).
Le projet weboob (http://weboob.org/) a cette visée là : d'utiliser différents fournisseurs de services en restant sur une même application, neutre vis à vis des fournisseurs (par exemple l'application traveloob de weboob)