Comme évoqué ailleurs, le principal problème est qu'Android est conçu comme un système d'exploitation portable, pour fonctionner sur une grande variété de matériels. Il s'appuie également sur un cadre et un langage familiers à de nombreux développeurs mobiles existants.
Enfin, je dirais que c'est un pari contre l'avenir - quels que soient les problèmes de performances qui existent deviendront sans importance à mesure que le matériel s'améliorera - également en amenant les développeurs à coder contre une abstraction, Google peut déchirer et changer le système d'exploitation sous-jacent beaucoup plus facilement que si les développeurs codaient avec les API POSIX / Unix.
Pour la plupart des applications, la surcharge liée à l'utilisation d'un langage basé sur une machine virtuelle par rapport au langage natif n'est pas significative (le goulot d'étranglement pour les applications consommant des services Web, comme Twitter, est principalement la mise en réseau). Palm WebOS le démontre également - et utilise JavaScript plutôt que Java comme langage principal.
Étant donné que presque toutes les machines virtuelles JIT se compilent jusqu'au code natif, la vitesse du code brut est souvent comparable à la vitesse native. Un grand nombre de retards attribués aux langages de niveau supérieur sont moins liés à la surcharge de la VM que d'autres facteurs (un runtime d'objet complexe, une vérification de «sécurité» de l'accès à la mémoire en vérifiant les limites, etc.).
N'oubliez pas que quel que soit le langage utilisé pour écrire une application, une grande partie du travail réel est effectuée dans les API de niveau inférieur. Le langage de niveau supérieur enchaîne souvent simplement les appels d'API.
Il existe, bien sûr, de nombreuses exceptions à cette règle - des jeux, des applications audio et graphiques qui repoussent les limites du matériel téléphonique. Même sur iOS, les développeurs se tournent souvent vers C / C ++ pour accélérer dans ces domaines.