Actually, it's only "simpler" in that you are familiar with it and perhaps your programming environment of choice lacks good support for multi-threaded programming. It's certainly not "simpler" from the perspective of resource efficiency (e.g., it's so easy to spoil Copy-on-Write's benefits) and usually it asks some other process to do the hard work of coordination. From the perspective of correctness, introducing multiple processes to your system greatly increases the number of failure states and vastly complicates error recovery.

I think you're dismissing the state of the art on multiple fronts, as is the article. From single-variable STM (of which Haskell and Clojure both have excellent implementations) to battle-tested and well-understood concurrency primitives in the Java standard concurrency library, multi-threaded programming is more approachable and performant now than it has ever been.

But the article is oddest in that it seems to hold up Erlang as a way forward, but Erlang is just a different model built on top of thread-based concurrency. If the argument is the old pthread-ish model of "1 thread per call" and very primitive synchronization tools are antiquated... then who is he arguing with? Erlang uses actors, Haskell uses sorcery (really, it's fancy; they turn normal-looking threaded code into erlang-ish sliced execution under the covers), Go uses fancy structures along with coroutines, Java uses Executors to implement higher-level work off patterns, and everyone is using Futures and Promises now.