The zone of impurity is very hard to constrain. Consider an phone with a client app that is out of storage space and can't download an update. Even if you "solve" the problem by forbidding older client versions from connecting, you can't make that cutoff too quick or you'll annoy users. So, you're talking about a lag time of at least weeks on every deploy, which means you've already started multiple new deploys before the old ones drop out of support window. A large system is always in the state of transition.
Clients that our outside of your window of control obviously can't be part of the zone of purity. In that case the management practices in the article applies. You need to differentiate and control what you can, which is exactly what haskell does.
What I'm referring to is that a HUGE number of systems that can be in the zone of purity, aren't. Microservices architecture does not colloquially exclusivey refer to systems outside of our control, it refers to building a constellation of services WITHIN our control (think of a monolith within our control, but just broken down to microservices for the unintended purpose of introducing all these extra impure issues).
So a huge number of problems people face in distributed systems will be EXACTLY similar to the same problem faced by the phone with a client app simply because of bad choices and NOT because the component lies outside of their control. Like why am I facing this update problem between two services I control? Why should I even face this problem in the first place and why did I make this problem exist when I CONTROL both services? There's no excuse here.