If parallelism is off the table I would be surprised by any disagreement.I doubt any one finds control inverted style of programming more pleasurable (I.e. Callbacks) than code that looks synchronous but executed async. One thing that does require watching out for is that there are no blocking calls. Green threads, coroutines, fibres seem so much nicer as a programming abstraction. Is this view even contentious?
This does not address parallelism though. These are about exchanging control between stacks of execution, only one such stack is active in an unit. There could be multiple such units though and rub lies in should they synchronize by messages (less buggy) or shared mutable state (at times faster if serialization is expensive. Think Python).
A model that I like is different units of execution ( threads) in a common address space, each hosting coroutines or their ilk with the units sync'ing exclusively by message passing but without the need of serialization because they live in a common address space.
But it wasn't necessarily the threads, so much as the fine-grained locks.
I'm talking about threads-the-programming-model, where we don't throw away the gains we made with structured programming. I suppose I ought to get off my duff and finish the blog post that explains exactly what that means, but if you know what structured programming is, that's actually enough to explain what I mean. (It's just that nowadays most people don't actually know what it is, not because they have no familiarity with it, but because they have too much, and don't realize that it was not actually the "ground state" of programming but actually a hard-fought advance, which we are all collectively on the verge of spending the next, oh, 5-10 years painfully rediscovering the value of.)