Because that is an herculean task, given the hardware semantics, the amount of languages that target PTX, the graphical debugging tools that expose every little detail of the cards like debugging on the CPU, and the libraries ecosystem.

Any Cuda-compatible software layer only has two options, be a second class CUDA implementation by being compatible with a subset like AMD ROCm and HIP effforts, or be compatible with everything always playing catchup.

The only way is to use middleware that just like in 3D APIs, abstract the actual compute API being used, as man language bindings are doing nowadays.

Worth noting that cuda seems prone to using inline ptx assembly and that latter is really obnoxious to deal with on other platforms.

Implementing programming languages and runtimes is pretty difficult in general. Note that cuda doesn't have the same semantics as c++ despite looking kind of similar. Wherever you differ from expected behaviour people consider it a bug, and implementing based on cuda's docs wouldn't get you the behaviour people expect.

Pretty horrendous task overall. It would be much better for people to stop developing programs that only run on a gnarly proprietary language.

CUDA was redesigned to follow C++'s memory model introduced in C++11, yet another compatibility pain point with other hardware vendors.