I'm left completely scratching my head here. I use all three of these packages routinely with Twisted.
Are you saying that you are trying to share the reactor thread while blocking with, for example, requests.get()? Obviously you can't do that - why would you even try? Just run requests.get() on another thread.
On the other hand, if you, for example, use deferToThreadPool with a bunch of Django ORM calls, you can happily go on serving requests from another ThreadPool. This works like gravy.
These various adapters that you've described: in every case, their existence is not a testament to an inability to run their respective libraries' blocking I/O with Twisted; on the contrary, they provide support for actually using them with a proper Twisted protocol.
The fact that so many of them exist doesn't mean that Twisted is doing anything wrong, it means that people really like Twisted and want these various packages to be able to talk directly to a Protocol or Producer without having to maintain that code in their project.
If you want to run Django in Twisted without hendrix, go ahead: use the WSGIServer built in Twisted. However, you'll probably find that you are building lots of tooling around the awesome things you want to do with Twisted (ThreadPool tuning, websockets, concurrent functions running in views, and much more). So, instead of having to write all that yourself, hendrix ships with it.
For my practice, the Twisted ecosystem is the finest part of Python.