> Particularly when they don't seem to have significantly investigated the work of a team that's been working on the "fast python" problem for the last 15 years.

If you mean PyPy, PyPy was from the start intentionally "meta": it was never made to be simply a Python with a faster interpreter(s) and fast JIT(s) working in sync, like the modern Javascript engines work. It was intentionally a reimplementation of Python interpreter and all possible code in Python (that's where the name PyPy comes from), and then what's "optimized" is everything together: the new interpreter and the new Python implementation written in Python, all while generating a real C source. Which is then compiled as a normal C.

It's obviously too "meta" goal compared to the approaches used by fast Javascript engines, even if they also use some Javascript implementations for some library functions. When your starting goal is to "do everything in Python" you have already blocked yourself from being able to take the really best possible approach on every level of the engine. And even being meta enough, they still write:

"in code like this with a string-valued foo() function:"

   for x in mylist:
       s += foo(x)

"the JIT cannot optimize out intermediate copies. This code is actually quadratic in the total size of the mylist strings due to repeated string copies of ever-larger prefix segments."

So yes, there's definitely a room to make a faster usable implementation compared to the current PyPy. But it is a hard work, and needs a very focused and knowable leader(s), willing to take the "harder" approaches on every level, when needed. "Harder" than "we'll do everything in Python and only then optimize the whole thing together."