Squeak on the iPhone
news.squeak.org
news.squeak.org
Every processor cycle you execute on a mobile device drains your battery. If your interpreter runs 1/10th the speed of native code (a reasonable ballpark figure) then you are going to be burning 10 times the battery in the CPU. (more or less)
Don't disrespect your user. Code native.
Faster development time: it's important to know if people even like your app, and a quick prototype is often a good idea.
Let more users write apps in the first place. Maybe Joe Schmoe has a neat idea for an app that would be great in his industry, but isn't much of a coder, and would simply get stuck with a more complex language. Keep in mind that this may be something as simple as a user writing code for their own phone, so they know what kind of tradeoff they're making.
If you're using the right kind of languages, you can write the control code in a scripting language, and write speed-critical code in the lower-level language.
Obviously, I'm biased, as I've spent massive quantities of time working on Hecl, and have seen firsthand that I can write small, but useful applications on platforms as limited as Nokia's S40 series (from 5 years ago).
What? Every VM worth its salt compiles the bytecode to something just as good as optimized C at runtime (it's called "JIT"). The JVM does this, Parrot does this, and even SBCL does this (even code you type into the REPL!).
So basically, there is no performance reason to avoid VMs. If you're wondering why languages like Java and Lisp run slower than C on average, though, it's because the constructs are different. C is assembly; everything you write is basically a CPU instruction. CPU instructions run really fast. Things like memory management, cons cells, OO system MRO lookups, etc. don't run all that fast.
So basically, you pay for expensive language features; you don't pay to be running on a VM.
Finally, is it more disrespectful to provide a neat tool that burns battery, or to not provide the tool at all?