The nature of implicitly yielding coroutines requires monkey patching significant parts of the core library. This is a brittle design and as a result, Eventlet is frequently the cause of bugs in Nameko.
Many libraries cannot be easily used with Nameko because they are not "eventlet-safe", meaning that they are not monkey patched and therefore operate outside of the Eventlet scheduler. This includes most libraries that perform I/O in C extensions.
Gevent is another library that uses an implicitly yielding coroutine model, but it is more widely used and stable than Eventlet. Additionally, more libraries that use C extensions are compatible with Gevent because it is a larger ecosystem that is worth explicitly supporting (e.g. gRPC)
Since Eventlet and Gevent have the same programming model, it should not be wildly difficult to provide an abstraction (e.g. in nameko.concurrency) that supports both libraries as a backend.
Nameko is quite opinionated about concurrency. Specifically, workers are single-threaded and stateless; all I/O must happen in Extensions, and Extension threads should be created via ServiceContainer.spawn_managed_thread.
Therefore it might be possible to go further and allow Extension authors to use asyncio or another explicitly async concurrency model. It may be possible for a Nameko runner to execute in "explicit" or "implicit" yielding mode, choosing between either all-implicit or all-explicit sets of Extensions. Or it may be possible to mix and match implicit and explicit extensions in one runner.