I think for C# one of the strong async use-cases was the same one as for Javascript having async/await: UI programming. UI environments are mostly single-thread

I think for C# one of the strong async use-cases was the same one as for Javascript having async/await: UI programming. UI environments are mostly single-threaded, and if you want to modify UI elements you have to perform that operation on the UI thread. Doing e.g. a HTTP download in a background thread and directly manipulating a progress bar from there wasn't possible. With async/await that can multiplex all those async tasks onto the UI thread this now gets feasible. With the move to more declarative UI patterns this argument might now get more mood, but I don't have enough recent experience to tell. On the server end, I strongly agree with you that for 95% of applications a threaded environment - and even using plain OS threads - would likely be easier and fast enough. But I guess everyone also wants to support the remaining 5% of applications, like "build a 100k clients proxy server". Btw: Fibers can also be viral. E.g. if they are multiplexed on a single OS thread (non work-stealing scheduler) you still can't block in them, and need fiber-aware methods of everything. If you use a work-stealing scheduler then methods which use thread-local storage might be subject to undefined behavior, because the currrent thread might change inside the execution of the function at an invisible yield point.