The JVM does support hot code loading. In statically typed languages like Java it's not so easy to use, but there's no reason not to use it for Erlang.
> and it definitely doesn't work in a soft-realtime manner
You're misinterpreting. While the JVM, unlike Beam, has a single heap (which brings significant performance advantages over Erlang's copying), its GC is so much more advanced than Beam's, that in spite of this limitation there's no reason it shouldn't behave as well as, or better, than Beam.
Also, this is a solved problem. If you want to absolutely guarantee no pauses at all, use a commercial JVM that guarantees that.
> you're just running a pretty-useless-for-its-intended-purpose subset of the language.
This is a huge exaggeration. Beam has its issues as well, and if you can deliver better performance overall a lot of people would gladly take it in exchange for the occasional pause (or pay money to eliminate the pause).
> Erlang is a painful language to code in; you don't do it because it's pretty. You do it for what the BEAM VM and the OTP libraries give you: the ability to spawn 100k processes representing, say, people's phone calls, or their MMO game sessions, and not drop any connections for something piffling like a garbage collection pass, or a bugfix. I would expect no less of any "universal" VM. (Though I might, of course, expect more. It should probably be able to do CPU-bound stuff like large matrix multiplications without dragging the rest of the VM down, for example.)
The JVM can deliver all that, with awesome performance to boot.
I have the utmost respect for Beam, but the JVM can give Erlang a different set of tradeoffs that is very attractive in many circumstances (I would argue in most). No one can take Erlang's valuable concepts away from it. That doesn't mean running it on a different VM implementation is not beneficial for both Erlang and JVM communities.