it becomes increasingly likely that your specific program will benefit from one of these feature performance enhancement

We've all heard that a lot! Assuming a linear progression of improvement is unrealistic. If performance isn't better than Perl overall now -- with allegedly a better internal data model, a better VM, and a language that's easier to optimize -- where's that speed going to come from?

I'm sure a few people here remember the Parrot benchmarks of a decade ago that showed raw Parrot performance (PASM, PBC, and I believe PIR) was generally better than Perl performance, and that was without the sort of optimizations that could have been possible (escape analysis, unboxing, JIT).

Then, there is also more in-depth work going on on the Rakudo compiler / MoarVM optimizer (including JIT optimizing).

The last time I looked at Moar, it didn't look like it was designed for the sort of optimizations that people think of when they think of JITs like in JavaScript, Lua, or the JVM. When we were designing the optimized version of Parrot called Lorito, we looked at Squeak/Slang and JavaScript for examples, focusing on optimization possibilities such as unboxing, using primitive types where possible, avoiding memory allocations where possible, and (above all) not crossing ABI/calling convention boundaries you can't optimize across.

I could be wrong about all this -- I haven't looked at any of this code in any sort of detail in seven years -- but as long as the optimization strategy of Moar/NQP/Rakudo is "write more stuff in C because C is fast", it'll struggle getting to performance parity with Perl, let alone surpassing it. The fact that it's been years and the Rakudo stack is still four or five times slower than Perl does not give me much confidence that Rakudo will ever reach JavaScript levels of performance (let's be conservative and say it needs to be 20x faster for that) without yet another rewrite.