It seems to me that author is convinced about distributed systems or it's their whole identity and try to come up with reasons to feel better or something.
It's not that you don't ever need distributed systems, but that's the exception when you do, not very frequent.
"Simplicity is a property of systems, not components. Systems include people and processes."
How you achieve that simpicity is at the heart of what I consider 'software engineering' vs just 'programming'.
If you have a small org with small number of teams then you are right, but still what qualifies as "small" or "large" is not really clear and people seem to jump into the distributed systems architecture way too soon.
It makes the whole thing murkier, because it's unclear to me what exactly they advocate for. Multiple servers? Microservices? Just running multiple services but don't go too crazy on the micro? (Many "focused" small monoliths handling cross cutting concerns might be considered microservices but are not as micro as some people do, etc). Maybe running multiple servers with some distributed systems technology but not actually messing with distributed systems as product part (k8s, some easy to distribute clustering databases, etc)? All of that simply doesn't fire for me when I see "distributed systems".
One could just as well read it as arguing for actually going deep into distributed systems theory and practice, integrating those ideas in your product, designing your software to use distributed persistence systems instead of single "coherent view" SQL or other database, etc.
That said, I do agree with the general point of needing more than one computer. But most people probably just need two, one for backup, far from “distributed system” in the traditional sense.