Tant que Mozilla n'arrivera pas a des perfs équivalentes (allons, prenons large, disons 90% du natif, ça fait quand même après peut-être 10% de durée de vie de la batterie en moins, déjà pas très appréciable), c'est utile pour… Avoir des perfs (ou de la batterie, au choix).
Native Client non plus n'a pas 100% des perfs "natives" hein. Et les 50% de asm.js ne sont que ce que un type seul a été capable de faire en 3 mois. On ne sait pas encore jusqu'où asm.js va pouvoir aller mais a priori on ne voit pas de raison pour qu'il plafonne en dessous de ce que peut faire un autre langage intermédiaire.
D'autre part ton commentaire suggère que tu crois que l'utilisation du CPU est proportionelle à la consommation de batterie; ça n'est pas le cas.
Argument dépassé (PNaCl), et si c'était un argument, il aurait suffit à Mozilla de faire la version portable.
Tant que PNaCl n'est pas sorti il n'y a aucune raison de croire que c'est faisable, puisque PNaCl cherche à utiliser la représentation intermédiaire de LLVM et les devs de LLVM ont averti que c'était une mauvaise idée.
Et surtout n'a pas été proposé par Mozilla.
Mozilla n'a jamais proposé un ensemble de technologies qui viendrait à remplacer tous les standards du Web par un ensemble d'APIs décidées par Mozilla seul. Ça demanderait un sacré culot. C'est ce que Google fait avec Pepper.
Le parallèle avec H264 ne marche pas. La raison de rejetter H264 initialement n'avait rien à voir avec la raison de rejetter Pepper. H264 était rejeté parce que non libre de droits et donc impossible à implémenter directement dans Firefox. Le problème avec H264 est que Firefox va devoir se reposer sur les codecs système ce qui va conduire à des cas où une même page Web peut s'afficher ou pas suivant des détails de ton système. C'est un problème de portabilité.