Curiously enough, all of the features you've mentioned are doable on the JVM, even without TCO support (I know this because I've worked on implementing them in https://github.com/puniverse/quasar – well, except for the "budget-based yield" but that's a minor change). The general idea is that instead of providing the implementation baked into the VM, you inject it into the compiled code using bytecode instrumentation (at load or compile time).
What truly separates BEAM from the JVM is the almost total process isolation, particularly, as you've mentioned, in the case of memory allocation and reclamation. This difference, however, entails tradeoffs – sometimes you'd want the one and sometimes the other.
Not so curious; this is the true meaning of Turing-completeness at work (not the pop meaning programmers use in reference to programming languages.) You can always write a virtual machine with semantics Y, that both executes on top of another Turing-complete abstract machine with semantics X, and reads X machine-code--and thus get semantics Y on machine X.
What you've effectively done is to just skip the naive VM-emulator step, and move to the optimization of dynamic recompilation, where you move the state-transitions and additional semantics from the X interpreter, into the chunks of X machine-code it would operate on. You've still implemented a Y VM; it's just distributed throughout the code output by the compiler.
[For the same reason, I'm planning to port BEAM to asm.js. Why? Because pre-emptive concurrency is just an abstract-machine semantic, and you can get it from a non-pre-emptively concurrent platform using the exact logic above. No more callbacks! (If everything that uses asm.js has Web Worker support, though, they could be used as run queues vis. BEAM's SMP support, leaving the UI thread a lot less stressed.)]
Well, Yes, but the result still benefits from the JVMs awesome performance with regards to optimizations and memory management, and its terrific monitoring and management tools. So, true, you lose some of BEAM's process isolation, but you gain performance and tooling.
So I don't know if the JVM is universal in the sense that it can provide an efficient implementation for all known or future languages, but it can certainly serve as a very good Erlang VM.
Actually, Javascript is a bigger challenge than Erlang for the JVM. In Erlang there's no dynamic dispatch, while in Javascript you have nothing but. So a different kind of JIT might be better suited for Javascript.
What truly separates BEAM from the JVM is the almost total process isolation, particularly, as you've mentioned, in the case of memory allocation and reclamation. This difference, however, entails tradeoffs – sometimes you'd want the one and sometimes the other.