That's because you would usually rewrite your Python program in something like C++ if you realise that it's too slow and you need the speed of a compiled language, despite the enormous extra complexity to create and maintain it that way.
You wouldn't go back the other way because it's very rare to go to all that extra effort writing in a more efficient language only to realise that the slower performance of Python would've been adequate after all. And, thanks to sunk cost fallacy, even someone that does realise it is unlikely to make the switch back.
There's no way you could convince me that writing your program in C++ is easier to code in, even for a very large system, than Python. C# maybe.
> Even many famous Python packages are now Python wrappers.
Of course! That's precisely because Python is much simpler to code in. If your Python libraries are wrappers around native code then you get the speed benefit without having to drop into those languages. (Plus they can release the GIL, allowing true multithreaded Python.)
If native coding languages were good enough then there would be no need for Python wrappers - you'd just call into the native library directly.
True but that's the problem. Once you have a big enough team, it becomes an uphill battle to maintain that.
The "faster to write" advantage becomes less relevant if most code is going to be auto-generated.
The "harder to maintain" might still remain more relevant.