I don't think the author took a position on synchronisation at all. He said you have to pick one to abandon of mutability/concurrency/interactivity and that abandoning mutability is horribly slow (because of the need to copy things). And that isn't technically accurate because you can abandon mutability and not copy things. If you have a 1MB int->int associative data structure and need to change one entry, then you can reuse most of the MB (it isn't going to change) and get away with writing a couple of integers.

And that could be substantially faster than a mutable approach when you need to make a genuine copy of the 1MB structure with a small change and keep both, because you can't structure share and you will need to copy the whole MB. Obviously situation specific, and I'm sure there are edge cases where immutable lookup tables fall apart. I haven't met one myself.

I don't disagree with the article exactly, I do think abandoning mutability is necessary. I just don't think his argument that it needs to be slow is good. If you abandon mutability, "copying" data logically is extremely fast because you can skip almost all the IO for large objects. And copying a large object with a small change should be much faster in an immutable language because of structure sharing. Depending on the workload, that might be faster.