I'm not one of the people who ever shipped pre-cythonized code, but I think at this point it should be pretty safe to ship just your .pyx files and not the generated C files - at least if your reason for shipping the C code was "it will be hard for people to pip install things".

For other reasons, it's best to ship wheels anyway, and pip will prefer wheels over source distributions, so if you ship a manylinux wheel and a Windows wheel for each of the most popular Python versions, the majority of your users won't even ever hit the source distribution anyway. PEP 518 has been supported in pip since I think version 18.0, and PEP 517/518 support in pip landed in 19.0 (though it's been a rocky few months).

I do tend to live a bit ahead of the curve in terms of packaging because of my intimate familiarity with the topic, but I do think that we're at the point where the build-related problems you'll see from just shipping `.pyx` files are going to be pretty rare, if you do it right.

I hope this is something that improvements in Python's packaging story (specifically, PEP 518) should help with.
I see the current practice of including Cython's output in releases as a workaround for the fact that you can't (reasonably) specify Cython as a build dependency. Cython is a much lighter dependency than a C compiler -- though a less common one. When there's a reliable way to specify build-time dependencies, running Cython on each build will hopefully become the obvious way to do it.