I'd like to elaborate on the interesting ways Kelsey's transformation approach addresses the following features of virtual machines (from Ted Leung).
"Virtual machines get you portability, the ability to do JIT compilation (although this could be done in native code apps), and security (via sandboxes, etc)."
Portability Kelsey's approach gets you portability to any low level instruction set. Language providers translate to a high level intermediate language. In his case this is Scheme, which is essentially the call-by-value lambda calculus.
Only one programmer has to provide the translation to any specific instruction set, whether it is for a virtual machine or actual metal. Everyone else rides for free.
JIT The intermediate language can be passed around (in a concise format such as the one used by SISC) until such time as it makes sense to transform it into a specific low level instruction set. This has the benefit of delaying the commitment of target architecture longer than a virtual machine architecture provides. Specific distributed objects could be migrated to some unspecified target at run-time and compiled to efficient code, along the lines of Kelsey, et al.'s Kali Scheme.
Security This is the most interesting test of all of the high-level transformation approach. Basing the intermediate form on function application is a beneficial form of security. The high-level model of computation can be analyzed and/or encapsulated more effectively than a low level byte code.
Low level virtual machines are an undesirable model for security. Kelsey's mate Jonathan Rees describes how this alternative works in his and Kelsey's implementation of Scheme.