There is no physical possibility to simultaneously run more concurrent threads than exists logical CPU cores. Any attempt to run at once more tasks than exists cores means that there is scheduling and context switching overhead. Depending on the implementation details amount of overhead is different. For regular threads this amount is huge, it involves context switching (quite expensive operation by itself) and OS-level scheduling (with its own specifics, not necessarily optimal for particular application). For fibers/coroutines it's quite small, involves only app-level scheduling. But this overhead is still present.
Carefully written pure event driven application based on callbacks or promises has virtually near to zero such overhead. What is even better - it automatically establishes optimal order of execution of all parts of code. Any external scheduler will be worse in this regard. This is the primary reason why I see no big value in fibers/coroutines. The only reason of their existence is ability to continue writing classic synchronous code.

One curious observation: classic synchronous code is imperative and has quite a lot of issues (exceptions, error and null values handling, for example). Reasonable solution is wider use of FP code approaches. But most FP approaches are heavily based on passing functions, i.e. using kind of callback. So switching to FP code style makes use of reactive approaches quite natural.