Intuition is relative: when I first encountered unix-style synchronous, threaded IO, I found it awkward and difficult to reason about. I had grown up on the callback-driven classic Mac OS, where you never waited on the results of an IO call because that would freeze the UI; the asynchronous model felt like the normal and straightforward one.

> It’s unintuitive and hard to learn.

Funny, because it was supposed to be more intuitive than handling concurrency manually.

It is an intrinsic tradeoff. With async there is significantly more code complexity with substantially higher performance and scalability.

If you don't need the performance and scalability then it is not unreasonable to argue that async isn't worth the engineering effort.

I can't follow that it's hard to learn and unintuitive

What's awesome or rewarding about it?

It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance.

Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains.

And the designers of Go and Java did just that.

Or... we've learned it and don't like it? For legitimate reasons?

Really? async/await is the model that makes it really easy to ignore all the subtleties of asynchronous code and just go with it. You just need to trial and error where/when to put async/await keywords. It's not hard to learn. Just effort. If something goes wrong, then "that's just how things go these days".