The article is explicitly saying that green threads are better than callbacks, promises/futures, and async/await, yes. It is definitely making a comparison between those two styles of implementations, and it is saying that (what you call) shared memory multithreading is better than callbacks.
I want to point out though that the article is not claiming OS 1:1 threading is better than async/await/callbacks. OS-level 1:1 threading is too heavy, and it's obvious that many programmers reach for callbacks to handle high concurrency evented I/O. The article is claiming that languages that allow a blocking style of programming via green threads (to still get the same high concurrency) allow a more natural way to program.
Your point was the article was one of "the most inadequate articles on concurrency ever written." I agree. It wasn't trying to be a complete article on concurrency. It says nothing about the actor model.
Then you said it "Even managed to claim shared memory multithreading as superior to all other concurrency models." The article doesn't talk about all other concurrency models. It only talks about the programming styles that "shared memory multithreading" is better than.
> The article is claiming that languages that allow a blocking style of programming via green threads (to still get the same high concurrency) allow a more natural way to program.
I would say this is a subjective conclusion at best. We might ask instead which model facilitates collaboration. That is in a large, very concurrent program composed by many developers which model is going to lead to more robust code. The interesting thing about M:N programming is that large programs in 1:1 languages (Java, C#) tend to converge on to the M:N model. Many large concurrent Java programs therefore end up involving several carefully monitored threadpools with well-defined contracts that describe how work gets scheduled and distributed between the threadpools. But this is not an argument for M:N languages precisely because the "problem of scheduling" often tends to be very domain specific. Other programs have lots of success with the Reactive model because they're never truly blocking and waiting for information that hasn't arrived. Some find success with Actors. It's worth considering then that different concurrency problems call for very different solutions and saying one model is better than another is erroneous.
There are different concurrency models. Shared memory multithreading that Go uses is one. Green threads, goroutines, 1:1 threads, M:N threads are all part of that model. It has synchronous APIs, concurrent memory access and lots of problems. Callbacks, promises/futures, async/await all deliberately chose a different model, that doesn't have those problems and instead are programmed asynchronously. Their whole purpose is to enable programs that only explicitly give up control. So you can't claim they are the problem if they don't allow implicit blocking, as this is the reason they exist and the way they avoid all of the problems shared memory multithreading has.
I want to point out though that the article is not claiming OS 1:1 threading is better than async/await/callbacks. OS-level 1:1 threading is too heavy, and it's obvious that many programmers reach for callbacks to handle high concurrency evented I/O. The article is claiming that languages that allow a blocking style of programming via green threads (to still get the same high concurrency) allow a more natural way to program.
Your point was the article was one of "the most inadequate articles on concurrency ever written." I agree. It wasn't trying to be a complete article on concurrency. It says nothing about the actor model.
Then you said it "Even managed to claim shared memory multithreading as superior to all other concurrency models." The article doesn't talk about all other concurrency models. It only talks about the programming styles that "shared memory multithreading" is better than.