A C extension is far preferable when you want to code in C, either to write a new data type[1], or write a Python frontend to a C library[2] that is too complex to be well supported by simple FFI.
I think people use Cython more internally when they value the maintainability of "mostly Python" over the fact that it's slower than what native C would get them.
You have a quote for that? Cython code, in the context of "C-extended-python" probably never is slower than native C. There has been a lot of work over the years to make sure of that.
Now, if you want to compare it to "a C program/library in the wild", then we are not comparing apples to apples. The whole point of Cython is inserting C code into a Python module, to have (high performance) C code inside a Python environment.
Cython makes you do more work to avoid the interpreter. C makes you do more work to involve the interpreter.
> There has been a lot of work over the years to make sure of that.
Some cython code can compile close to the C code you'd write.
But that's not how it's likely to be used, because the design pushes you in the opposite direction by default, and the value of Cython is that it's far faster than vanilla Python, and the painless interop.
Huh? Cython tries, but it's not exactly optimized hand-coded C. And it works better for some things (e.g. numerical typed code) than others.
Or any other language that supports C FFI.