I don't have an informed answer, and may be you know all of this already.

(I only used pyo3 once in one of my projects, and didn't know about this new experimental feature, I also only used it to call python code from Rust, which is the other half of the crate, so to speak.)

https://github.com/PyO3/pyo3/blob/main/guide/src/async-await.md

Python awaitables instantiated with this method can only be awaited in asyncio context. Other Python async runtime may be supported in the future.

So the runtime here is from the python side. And my first guess would be that support doesn't extend to use-cases where special (Rust) runtime support is needed, like the typical io (and sometimes time) features of the tokio runtime that are often used.

Maybe the reference to "Other Python async runtime" in the quote above is hinting at something that may support such use-cases in the future.

If your Rust code doesn't work without using one of the enable_() methods here, then, that's probably your answer.

If your goal is to just .await some future that require the Tokio runtime you can use the async-compat crate.

I'm not familiar with pyo3_async, but I don't think you can force Python asyncio to use the Tokio event loop. This is discussed in the documentation of a different PyO3 async crate, pyo3-asyblncio: https://docs.rs/pyo3-asyncio/latest/pyo3_asyncio/#why-two-event-loops