Technically true, but in practice you’re constrained by whatever is provided by the ecosystem. And the truth is that many Rust projects were forced to choose async or sync, so these are often disjoint and fragmented. Even within async, crate authors need to pick and choose which async ecosystem to support, due to lack of support in std for spawning tasks and running simple IO, which most projects need. This is slightly alleviated by the Tokio hegemony, but that itself is a deferred migration minefield for Rust to handle.
Libraries don't just sprout out from nothingness, someone has written those. And if there isn't a library that suits you, that someone can be you then. Key observation is that the ecosystem is only additive, it doesn't deny you of anything.
This is true to an extant, except it's also a cultural problem: it spreads across crates, and soon you've got tokio spread everywhere.
But it's also a concern for me that a language feature was added that requires runtime framework support to function. This is bad separation of concerns.
It (async) is viral syntactic sugar that doesn't need to exist; asynchronous programming has been done for decades without it.