If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single-threaded program, it's always safe to call malloc() after fork(). In a multi-threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock.

My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.

I just want to be able to say "do this thing or time out in 5 seconds", and that's like all the 'async' I need in rust. Everything else, nah.

But that's just me - many people need these 0 cost abstractions, this is Rust's focus, and I'll have to wait for the higher level stuff for my projects.