Many web apps are indeed suited as a logic sprinkled atop several *aaS endpoints. Music streaming, social networking, collaboration and such.
This client-side logic can be made to run really fast with the evolution of JS engines and now also WebAssembly. Meanwhile communication cost is always bound by signalling over wires times number of endpoints. More time waste comes from data redundancy invoked by a physical separation of services (severity depends on the app nature). Within the fastest client side possible, overall latency will be capped by messaging.
Still all is well while you have 3-4 endpoints to mash up: probably staying within 1-2 seconds of psychologically acceptable latency so that your user won't switch to something else too fast.
Things shall not be that funny once you need to integrate more than 5 endpoints. Messaging overhead turns into seconds and tens of seconds. A good example comes from business software. Parts of a typical ERP suite are tightly coupled on data: should you have a person, it is the same person for accounting, CRM, BPM, project planning etc. Integrate these parts the SOA way and obtain irreducible chatter between endpoints and thus slow UX.
It was observed that up to 40% of total system workload in typical SOA-style ERP suite is in data exchange between the core ERP system and the satellites. One has to control the flow between endpoints transactionally, hence aggressive caching is not only very complex there, but would not actually work.
Having that in mind and thinking of the enterprise software, I am personally in big favour of approach that SAP HANA guys took, where the business re-unites all the apps on a single platform and lets them share data in transactional way. This is contrary to the widespread belief that future enterprise systems should be a collection of SaaS components integrated through standard interfaces.
The management of redundancy is prohibitive, and extra workload from shipping data back and forth creates a bottleneck. And, by the way, there is no need to implement physically disjoint microservices to achieve great system modularity, neither should you build monolith anymore to address performance problems. Leverage the capabilities of modern software platforms and "do microservices the right way".
In the world of enterprise software understanding comes right now that data integration always beats messaging in total cost of ownership.
Surely there is no sliver bullet, what is good for enterprise software might not suit other domains. But just imagine when one builds a game engine where polygons are rendered on one machine, physics calculations are done on the other machine, multiplayer logic is on third, and all flows and mixes up through the user machine. Wouldn't it be kinda slow? But enterprise software done via messaging-based integration isn't really far from that.