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.