None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism.
In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.
This is not the case with Python, Smalltalk, Common Lisp, etc.
To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.
Python's semantics make both of those prospects incredibly dubious.
So I am lost, are talking about Python JIT compilers or C performance?
Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code.
At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support.
The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries.
They are as much Python as they could be Tcl.
Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
That person seems to just think that so long as the JIT is kinda fast, it's good enough. But that's really not the world we live in most of the time, especially if using that JIT broke binary compatibility with existing fast libraries.
In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.
This is not the case with Python, Smalltalk, Common Lisp, etc.
To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.
Python's semantics make both of those prospects incredibly dubious.