OS threads have a high real-world cost that limits throughput, and some things are much simpler to design in an async architecture generally. Context switching is expensive on modern systems, due to both CPU cache thrashing and implied resource cost. In many server applications the CPU will spend more time context switching in massively multithreaded architectures than actually running application code. An async architecture can complete tens of millions of independent operations per second in practice; the OS would have a difficult time just context-switching at that rate even if it was doing nothing else.

Furthermore, some classes of major macro-optimizations can't be implemented effectively if you do everything with kernel threading. This is the reason most modern server software architectures tend be thread-per-core pure async with no real multithreading per se -- it is for the performance.

At a more practical engineering level, these architectures are not more complicated, just different. Some things are much simpler to design because most multithread coordination problems go away. It is nice to be able to write virtually all of your code in single-threaded style where you don't have to worry about locking and consistency, especially as concurrency increases. On the other hand, you have to learn how to design schedules because the OS will no longer be doing that (poorly) for you. It isn't free in that you have to develop expertise in things you may not know but it is often worth it.