It is gratuitous to take the word "simpler" as some kind of proof that the person you are responding to is an ignorant who uses objectively bad tools. Reality is less clear.
"Simpler" clearly referred to the complexity and the mess created by synchronization in a shared-everything environment, which is where most languages are at with threading (Haskell, Clojure and Erlang are not most languages). This is a valid criticism. You may lose Copy-on-Write, but sharing everything by default, at a low level, does raise the need for complex synchronization, which has its own performance issues.
And this is very good reason to explore and use other concurrency models. This is something that you and the article and the person you are responding to all seem to agree on.
Except that you seem to take any interesting concurrency interface to be threading (no, goroutines are NOT threads) and you draw the strange moral that only the complex problems of threads can be addressed with nice tools and new ideas, but somehow not the problems of other basic concurrency models.
Assuming we have available helpful interfaces for using processes, threads and greenlets - all of which have been produced somewhere - the argument should be about the performance of the foolproofed backends. Preferably based on numbers.