While I am not certain what the GP specifically references, I can say that about 40 years ago the Actor model[1] was officially documented. The literature documenting benefits of an Actor model over a callback approach are easily found. For understanding the pain which callback-based systems often produce, a person can familiarize themselves with the Win32 API (disclaimer: this is a masochistic exercise not recommended for anyone).
1 - https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...
People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is.
Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be called from other async functions.
It would have been great if node invested in allowing many concurrent blocking JS threads. To see what that could have looked like, see Dart's Fletch project: https://github.com/dart-lang/fletch
Generators are just iterators, and are synchronous. The consumer asks for a value with next() and the value must be computable (even if that value is a Promise).
If you have an async function (one that returns a Promise or in the future a Stream), and you need to call it from a sync function, and somehow incorporate the future value into the return value of the sync function, you're stuck. You have to async-ify your functions all the way up the call chain.
With blocking this isn't a problem. We just need environments that make blocking cheap.
As for "having to change an entire call stack", that just stopped happening after a while. The rule of thumb was that if the function is impure (e.g. relying on mutable state) then it will likely become async, too. That lets me plan ahead.
It would make your comment much more helpful, IMHO.