"Microservices should be considered "pure"—for any given input there's an output or action"

True, but that is a very misleading way to look at it. A microservice performs a single isolated transaction in the context of a larger business context (saga) that is outside of that transaction. Thus, there are business-level failure modes that must be added to the saga.

What would be a simple operation in a system with global transactional consistency becomes a very tangled web in a microservice-based system. Someone needs to design that web.

Yes, you are right that each service is "pure", but the larger set of services must have many more kinds of service to handle all the many saga failure modes.

The only valid reason for using a microservice pattern is to achieve massive Internet-scale: only then can one justify decomposing logical business transactions into multiple separate physical transactions.

One argument often used for the microservice pattern is to decompose the information model into a service model; but one does not need microservices to do that. A microservice is a runtime and deployment pattern - not a service architecture pattern. Earlier decomposition patterns such as Enterprise JavaBeans achieve decomposition, but preserve global transactions. They are not as scalable though. Scalability is the justification for microservices.