Conforme mencionado em outro lugar, o principal problema é que o Android foi projetado como um sistema operacional portátil, para ser executado em uma ampla variedade de hardware. Ele também se baseia em uma estrutura e linguagem familiares a muitos desenvolvedores móveis existentes.
Finalmente, eu diria que é uma aposta contra o futuro - quaisquer problemas de desempenho existentes se tornarão irrelevantes à medida que o hardware melhorar - da mesma forma, ao fazer com que os desenvolvedores codifiquem uma abstração, o Google pode extrair e alterar o sistema operacional subjacente com muito mais facilidade do que se os desenvolvedores estavam codificando para as APIs POSIX / Unix.
Para a maioria dos aplicativos, a sobrecarga de usar uma linguagem baseada em VM em vez de nativa não é significativa (o gargalo para aplicativos que consomem serviços da web, como o Twitter, é principalmente a rede). O Palm WebOS também demonstra isso - e que usa JavaScript em vez de Java como linguagem principal.
Dado que quase todas as VMs JIT compilam para o código nativo, a velocidade do código bruto é frequentemente comparável à velocidade nativa. Muitos atrasos atribuídos a linguagens de nível superior têm menos a ver com a sobrecarga da VM do que outros fatores (um tempo de execução de objeto complexo, verificação de acesso à memória por meio de verificação de limites etc.).
Lembre-se também de que, independentemente da linguagem usada para escrever um aplicativo, muito do trabalho real é feito em APIs de nível inferior. A linguagem de nível superior geralmente é apenas encadear chamadas de API.
Existem, é claro, muitas exceções a essa regra - jogos, aplicativos de áudio e gráficos que ultrapassam os limites do hardware do telefone. Mesmo no iOS, os desenvolvedores geralmente optam por C / C ++ para obter velocidade nessas áreas.