Is there some reason Erlang had to be slow for single threaded things? Mixed language programming isn't desirable for many of us. I suspect Erlang could be fast, with just a few changes, but it never will be.
1) it was never seen as a problem because the erlang team believe (and i agree with them) that you best let specialists deal with their speciality are.
2) There were never an efficient JIT on the BEAM. This is something that is regularly looked at by the OTP team, but it would be a massive effort, just to try to approach effiency of what other language, that you can easily interact with, could do.
3) The use case are small. Let be honest. The amount of problems that are really only CPU bounded are limited in day to day work.
Parallelism is about performance, and it seems contradictory to do parallelism well on top of a slow language. Yes, Erlang can call out to other languages, but so can shell scripts.
Some other examples are live code loading, which means you can upgrade a system without restarting or interrupting it, the extensive tracing and statistics, etc. All these little things make it very nice to build and maintain a long-running service, but add up to make the VM slower. If you're doing batch jobs and have no realtime requirement, then the trade-off may not be so attractive.