One of the biggest strengths of Erlang (and Elixir by extension) is that they take the approach of finding practical solutions to real problems.
Sure, theoretically there might be a better solution than green threads, but like you said, we're still waiting for that better solution 30 years later. In the meantime, Erlang has been powering highly reliable and concurrent systems for ~30 years now.
Which I don't believe. Throwing away thread and managing it yourself and playing the game of will this code block the event loop is ludicrous.
BEAM VM does a very good jobs. It serves financial, large telecom, messaging, web and many other services. It is one of the marvels of software engineering. Not only does it provide this N:M scheduling well, it also provides process heap isolation between concurrency units (processes).
Heap isolation is very important, it increases safety, fault tolerance and provides guarantees that are just not there with shared memory model. Heap isolation is also other CSP/Erlang-like-clones ignore when they say they provide an Erlang-like environment. The only equivalent is really something like forking hundreds of thousands of OS processes [+]
> Once that deficiency is fixed (yes...we're still waiting after 30 years) green threads can go away.
I am not sure when it will be fixed. We'd need to be able to run one million OS processes effectively with the same latency and memory usage as what Erlang's processes currently have. We haven't gotten there in 30 years as you said, I don't think we are getting any closer. Sure there are machines that could probably run a lot more OS processes than before, but then putting an Erlang VM on the same hardware would allow running even more of its lightweight processes and so on.
[+] Another interesting exception could be Rust. If say threads were very cheap to create and could have millions of them, then could provide the same memory safety guarantees at compile time.
[1]Because insight at the system level is required to do effective scheduling and because the transition between the userspace's concurrency model and the system's typically introduces unpleasant limitations and sometimes bugs.
If you're saying that a thread/actor/CSP model of concurrency is better than "async" (callbacks) as used with JavaScript, then of course -- 100% agree on that.