I think this argument refers more to Rust not having built-in support for async from the language’s v1.0 rather than the design of the Tokio stack. That has definitely led to unfortunate incompatibilities between libraries built for the different runtimes. However, the Rust language team took a super methodical approach to async support and the way that more async-related traits are slowly being standardized (first Futures and hopefully Stream, AsyncRead / AsyncWrite at some point in the not too distant future) seems like a long-term-great way of building into the language the abstractions everyone can get behind while leaving room for experimentation. I’m sure others would have different takes but I’m a fan.
Personally I love being able to experiment on the bleeding edge but waiting for a stable implementation, even if it takes 3 years to reach discussion on the RFC's. There are crates if you need it today, which operate on best-practice, but for an official solution I accept that it may take time for it to achieve acceptable standard library inclusion.
