That sounds very close to a "No True Scotsman" type fallacy. I've done a fair bit of consulting in the past working with Scala, and my experience closely matches the one described in the grandparent post - the issues happened with veterans more than newbies in my experience (Although that's a function of mostly working with veterans and few newbies)
I have seen junior and senior devs (and myself sometimes) struggle with fancier asynchronous trickery. That's true, but I think it's shortsighted to write off that effort as compared to "just using executors" (whatever that means exactly).
For me there was a lot of learning (that often just felt like grinding), and I can confidently say that I'm leagues more productive than trying to mimic this with low level vanilla Java primitives.
I'm sure this would also apply with go channels, async/await, etc. Raising the bar of abstraction in this case can be valuable. As compared to something really high leverage like reactive streams it's just going to take a ton of code and be far less flexible in a naive approach (in most cases).
I've seen this same pattern with others. Is it worth the investment of time to get there? Not sure, maybe Go is a better set of tradeoffs for most, but I wouldn't go back to straight executors, locks, and the rest of the Java 1.5 concurrency offerings (which is what I thought the OP was saying).
