It's maybe not a "big" why, or one you care about.
So, someone has made python run on Foo platform, lets say a watch. If I have a pure python program I can run it on that watch with no more fuss. If I have to rely on a c library then I have to get that ported to Foo platform, maybe dealing with developer keys and making "authorized" signed binary, etc, etc. Pure python is orders of magnitude easier.
That is why "Pure Python" is a thing.
Several standard libs come in pure python and C versions cause pure python is an advantage / requirement for some use cases. And speed is for others.
"python some.py" is (in some cases) vastly easier than porting/compiling/signing C code.
Besides, Pymux is Python while tmux is C. I'm sure you can appreciate that adding a Python API to tmux would be non-trivial, both code-wise and politically.
You can see the quickstart at https://tmuxp.readthedocs.org/en/latest/quickstart_python.ht... and the API documentation at https://tmuxp.readthedocs.org/en/latest/api.html.
You can see the testcases we cover use real tmux sessions and monitor the state of the session / window / panes to assert the API functions correctly. https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite
As for pymux, Jonathan Slenders' work on ptpython [1] and prompt_toolkit have been quite nice when working with shell_plus in django or debugging python projects. He's good in this area. Agreed that it's a nice thing to have pymux there.
And agreed that adding native language extensions (python, ruby, etc.) to tmux would be complicated code-wise and perhaps not in the spirit of what it aspires to be. That said, on the tmuxp side of things, a lot could be improved. For example, switching tmuxp to use control mode (-C) and filing smaller patches to expand control mode's events in tmux(1).
tmux is comparatively rock solid.
I personally find this project interesting to see, although I won't be using it.
