> While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade
Yes... because perf hasn't really been a focus for Erlang until about 1.5 years ago. Various (usually academic) third parties have contributed big performance-enhancing patchsets (the earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis; etc.) but these have then languished, with attempts to further development on them slowing to a crawl over time. The patchsets were just "too big to be digested properly"† by a team of core maintainers who 1. didn't write the code, and don't fully understand it, and 2. who aren't CS academics themselves.
Each of these indigestible patchsets was eventually dropped, throwing away any follow-on in-tree work done to it, and dropping perf back to where it was before said patchset was introduced.
The new work is in-tree, done ground-up by the core maintainers themselves, and so is actually showing linear improvements in speed. This not only includes runtime speed, but also the batteries-included addition of long-ignored performance-oriented features, like atomic counters and fast global readonly modules (and the runtime itself being gradually rewritten in terms of these!)
† This is exactly why, in the Linux kernel, big patchsets aren't accepted as-is, but rather are required to be broken down into small changes that 1. can add value on their own, and 2. can be molded to fit the design philosophy of the kernel on their own. This is why e.g. the "containers" patch from OpenVZ was never pulled in; but instead, each bit of it was gradually reworked into the cgroups + namespaces code that powers Linux containers today.