I am sorry, I have to correct this.

A virtual machine simply emulates another machine architecture in software.

It's a computer science way of implementing an abstract hardware platform that insulates us from physical hardware issues. The VM machine code, called "bytecode", is also compiled and we call it "interpreted" because it's not run by a real processor but a software emulator which may be higher level.

Theoretically, and therefore also in practice, interpreted code by its very definition can never be faster than native code. There are other advantages to using a VM but this ain't it.

As a VM emulates another architecture in software, the best it can ever hope to achieve is speed just below the native code. A machine that executes code that executes code is slower than a machine that just executes code, period. The fastest VMs aren't really VMs per se, they don't interpret the bytecode but convert it to native code (JIT) and run it on the real CPU.

It cannot be more power efficient either, for emulation overhead means extra power usage.

It won't be less "buggy" as far as functionality goes. It usually does have much fewer security holes, because the VM is an effective sandbox and I suspect this is one of the reasons it was chosen here (other being hardware abstraction).

Remember, there needs be nothing extra in memory to run native code, the CPU and hardware are already there.

A VM is easier to work on because, at least theoretically, you develop for a fixed generic platform and don't have to deal with hardware variations. In practice this write-once, run anywhere concept has failed miserably IMHO (witness all the bastardized mobile Java implementations and how we can't run Android apps on a standard, fully implemented JRE).