JPC

Emulation has advantages over VMs because the host machine's hardware architecture does not have to be the same as the guest machine's hardware architecture.  They do, however, suffer from inferior performance (as compared to VMs), due to the additional layer of indirection and translation involved.  Being implemented in Java, JPC provides the user with more confidence in isolation/security than a native C++ emulator, because of the additional layering within a hardened container runtime.  C++ is a bit closer to the hardware, however, so it would perform a bit better.

I think the JPC team is a bit naive in their assessment that a hard disk image could be loaded from anywhere on the internet, so I would see this claim as an implied performance issue.  Operating systems and applications are designed such that the disk should exhibit latencies within a certain range, and when you try to make them an order of magnitude slower, unacceptable performance is a likely outcome.

With the way JPC has been architected, implementing an emulator for another processor architecture would be considerably easier than starting from scratch--a large number of components could be reused, as JPC abstracts most operations down to their logical equivalents.

With advances in virtualization technology, I can't see myself withstanding the inferior performance of an emulator, and I don't think it would be particularly useful to run any sort of modern operating system on a mobile device--with the current (improving) state of cell data networks, I think its much more useful to access  a remote machine through a VNC or RDP type connection from a mobile phone, than to try to emulate the entire x86 hardware stack and accompanying OS.