A downside of Cython is that to get significant performance benefits, one needs to add type annotations to Python code with a special syntax, which may decrease readability.
Note that Python 3+ does have type annotations. I believe the reason Cython doesn't use that syntax is that it pre-dates Python 3. It could be changed, however, to use it, but that wouldn't help much, as I will explain later.
Typescript already has syntax for typing, so ideally "Cypescript" wouldn't need any additional syntax.
As I explained above, Python also has syntax for type annotations.
However, Cython distinguishes between Python code and "C" code, between Python types and "C" types. In other words, Cython is a union of two separate sub-languages that share a common syntax: a language for writing Python, and a Python-syntax-influenced language for writing high-level portable C-semantics.
You would still need those two sub-languages in Cypescript.
Is there some technical hurdle here that I'm not seeing?
No. Someone just needs to do it.
Note that there is a social hurdle, though: CPython generates CPython extensions. It generally wouldn't work or at least not that well for users using PyPy, IronPython, Jython, Pyston, Pynie, or any other Python implementation. However, it is usually possible to convince a user to use a specific implementation, plus, the vast majority are using CPython anyway.
The same is not true for Typescript / ECMAScript. There is not a single ECMAScript implementation that dominates the market like CPython does, and users usually don't get a choice of their implementation. If I am using Edge, I am stuck with Chakra, if I am using Firefox, I am stuck with SpiderMonkey, if I am using Safari, I am stuck with Nitro. So, which one of those would Cypescript generate extensions for?
Personally, I don't buy this approach. If CPython is too slow running Python, the solution is not to make it easier to write C code, the solution is to make CPython faster so you don't have to.
The CPython developers ignore lots of research into building high-performance dynamic language implementations gathered over the last 60 years, sometimes with good reason, sometimes without, sometimes simply because of a lack of resources. (Compare the number of developers Oracle JDK or IBM J9 has with the number of CPython developers, for example.)
The Oracle HotSpot JVM is based on the Animorphic Smalltalk VM (just like V8, BTW), Azul Zing is based on HotSpot, IBM J9 is based on IBM's Smalltalk VM, and none of them actually make much use of the static type information in the bytecode, most of their optimizations are dynamic. There is little technical reason why a Python or ECMAScript execution engine shouldn't be at least as performant as HotSpot, Zing, or J9.