Threads are for working in parallel, splitting a single compute-intensive tasks into many.
Async is for waiting in parallel for disk I/O results, database queries, network responses, etc.
The former are for doing more work. The latter is for efficiently waiting for others to do their work without using a bunch of excess thread context resources.
You don't reduce complexity by ignoring the difference between two quite distinct use cases. That's false simplicity.
So if a green thread is waiting for I/O, another can use the CPU just fine.
Yes there's context switching but it does scale and code becomes simpler to write and reason about.
If the threads are cheap, there is no point in making this distinction, which greatly simplifies the language. And they can be, we just need programming languages designed for that.
You could argue that Go does this more elegantly with goroutines, but this further highlights the point that threads should not be a silver bullet to development models.
Instead of accepting this fact and using another language if threads are needed, Python has been doing various async-style things for years and pretending it's good enough, including what can only be described as cooperative multitasking, that horror from the early 90s.
Linear code is far easier to reason about, but that is easy to forget once someone has become accostomed to thinking in async constructs.
The thing is, there are only so many things a person can mentally juggle. Removing the consideration of a whole dimension of issues means the developer can take on more useful complexity.