Python has a culture that sees writing C libraries as "Python" code, hence why.

It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.

I should start doing numerical work in TCL and see how long it takes for me to get set to the mad house

Well, first step is to create bindings to the same libraries Python uses.

The problem is that Numpy is not in fact anything close to a thin wrapper around BLAS/LAPACK like people seem to think it is.

First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability.

You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.

Who singled out Numpy?

Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.

There are huge apps (such as Shopify) which will safe a lot of money by having more performant BE so they do invest heavily into it.

Python workloads, with deep pocketed backers, do spend more time inside GPU or C runtime.

I don't see how it's relevant given that YJIT didn't cause any compatibility issue whatsoever.

There's a talk from a couple of years ago by one of the YJIT developers that discusses this in some detail and it's more interesting/complicated than that. The whole thing is worth checking out but the specific section starts here

https://youtu.be/vucLAqv7qpc?t=937