To write fast Cython, you basically need to write in C and control everything including Python API calls.
No runtime will help with this.
That is another thing that is nice about Cython, you don't have to learn all of Cython to be productive. Take your existing python function and just add some type annotations and you'll see real performance gains. Then you can profile your code and see what the next bottle neck is and fix that and so on.
So, yes, Cython gives you the power to manually control the GIL and the Python API calls and manage your own memory management and layout for those corner cases where that is what you need. Most of the time you can happily ignore all of that and get almost all of the speedup available.
I would guess that there's a clear separation of responsibilities, and each of the two languages is very well-suited to what it's being used for. There's not really a whole lot of anxiety about getting Lua (or whatever) to pull out all the stops you see in a compiler like SBCL or interpreter like V8, because these communities were never looking for a single language that could cover all uses cases in the first place. To steal an analogy I used the other day from myself, I'm guessing they don't want a spork all that badly because they're plenty happy with using a fork and a spoon.
That's how the community of people doing scientific computing and suchlike in Python tends to feel about things, too.
It currently emits Cython for the C-backend (and PyIodide). It is very alpha currently, but if people are interested in helping, get in touch.
Yes, we just went through one "tough but important" transition (Python 2->3) and it sucks to have to do this so often, but it's the price we pay from making bad bets (in this case, unnecessarily exposing the entire CPython interpreter as the C-extension API surface on the assumption that it will never be necessary to make CPython faster because people who need speed will just write the slow parts in C).