Earlier quoted context omitted.
Given the not-all-that-great improvement of a targeted attempt to speed up Erlang with HiPE, I wouldn't hold your breath for how well a non-targeted approach would go. Unfortunately, Erlang-the-language has several features that seem to be fundamentally slow, in that I've never seen any runtime that goes quickly with them. (A lot of memory copying, for one, even after being as clever as possible with optimizations on…
HiPE was done a long time ago, and I don't think it tried to use any particularly sophisticated techniques even at the time. Modern compilation techniques such as powerful escape analysis and partial evaluation may be able to do something new. GraalVM runs Ruby about 10x faster than standard Ruby, for example.
Which puts it roughly up against the plateau I observe for dynamically-typed languages across the board, except LuaJIT (which AIUI compromises the dynamicness a bit to get there). Ruby is a great deal more than 10x slower than optimal (which is still roughly C, though keep an eye out on that as languages continue to challenge it).
Based on the way Erlang works, I wouldn't expect it to get much past two times faster than it already is no matter how much money is poured into it.
I remember hearing the line about how there are no slow languages, only slow implementations, back in the early 2000s, when we didn't have any implementations of dynamic scripting languages that had really had a lot of effort poured into them, by modern standards. In 2018, we have numerous such implementations with vast, vast amounts of work poured into them. They are faster than they used to be... and they are still meaningfully slower than optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't do all the bad things that Python or Ruby do to make them slow, but it does add a lot of memory copying that Python and Ruby don't do, and which is probably not as reducible as you'd like no matter how you optimized it (the low-hanging fruit, after all, is already in current Erlang).
To be honest, if you like Erlang but you need the next step up in performance and are willing to lose a few guarantees to get there (a very common tradeoff in optimization, after all), the answer is Go, not waiting for a much faster Erlang. Go is significantly faster than Erlang, Go does not have Erlang's memory isolation, and these statements are deeply connected together, not just coincidence.