The restriction to a polytree might be useful -- but only with quite a few more caveats. In the general case, this is absurd; having dependencies that are common to modules that are themselves dependencies of some single thing is not inherently wrong.

Now, if that common dependency is vending state in a way that can be out of sync along varying dependency pathways, that can be a recipe for problems. But "dependency" covers a very wide range of actual module relationships. If we move away from microservices and consider this within a single system, the entire premise falls apart when you consider that everything ends up depending a common kernel. That's not an architectural failure; that's just a common dependency. (Process A relies on a print service, which depends on a kernel, along with a network system, which also depends on the kernel. Whoops, no more polytree.)

This is the sort of "simplifying" heuristic that is oversimplified.

A useful distinction I've made before is that of technical vs business services.

This also mirrors the alignment that arises in tech companies between platform (very useful to be centralized) vs architecture. Platform technologies are useful as pure technology, and therefore horizontally distributable. Whereas big-a Architecture as a central committee died an ignominious death for good reason: product and business decisions require deep knowledge, and therefore architecture is simply a function a product team does.

I am old enough to remember when there were simply "services," and there was an understanding that a service was something a team or business function did, because it mirrored Conway's Law. The root of service is literally "serve." That there was a one-to-one correspondence between a software service and the team serving others was a given.

Microservices were a natural evolution of this. When growth happened, parts of those things improperly in a too-large service were pushed down so they could be used by multiple teams. But the idea of a hierarchy of concerns was always present in plain ol' SOA.