My take from the data presented in the article is fully different: both of the "acceptably fast" techniques use JIT to make the executed code fast. And the author avoids to consider what the JIT does. JIT means that effectively, at the end, the JIT engine produced the native code. The same code your real compiler would produce. All the processing before that phase is just to allow the clumsy "too dynamic" languages to be able to balance between the "do at least something" and "do something fast enough" (the second happens after the "tracing" code detects something is repated often enough. And the code that is actually important has to be run as often as it can).

But if you write the code that is from the start less "dynamic," you can get the quality code without all the engines in between and all the overheads that are incurred.

The "asmjs" achieves the speed because it is a protocol which allows the JIT to simply compile the whole big chunk of program to the native code at once, without all the tracing etc. And to have such a code at the first place, you need some less dynamic language, like C, as the source.

On another side, the programmers don't like to have to be "too specific" but recently more languages that gain popularity demonstrate that the types can often be inferred in the compilation phase and that such a code can be convenient enough for a lot of developers but fast too.

So, no, I don't think that the future is in PyPy. It exists only because the Python language "specification" (and the reference implementation) is too clumsy to allow clearer type inference. In my opinion, the future is in the type inference and the real compilation, not the clumsy-big-overhead virtual machines. Obviously, the developments that actually move in the direction I like are obviously: asmjs, Swift and Rust. Disclaimer: I know I'm biased in preferring, whenever possible, the compiled code to the interpreted or the JIT-ed. YMMW.