Assumed audience: People, especially (but not only!) software developers thinking about how to structure the systems they work in—and open to understanding why “hierarchy” is not always bad!
Hierarchies are brilliant systems inventions, not only because they give a system stability and resilience, but also because they reduce the amount of information that any part of the system has to keep track of.
In hierarchical systems relationships within each subsystem are denser and stronger than relationships between subsystems. Everything is still connected to everything else, but not equally strongly. People in the same university department talk to each other more than they talk to people in other departments. The cells that constitute the liver are in closer communication with each other than they are with the cells of the heart. If these differential information links within and between each level of the hierarchy are designed right, feedback delays are minimized. No level is overwhelmed with information. The system works with efficiency and resilience.
Hierarchical systems are partially decomposable. They can be taken apart and the subsystems with their especially dense information links can function, at least partially, as systems in their own right. When hierarchies break down, they usually split along their subsystem boundaries.
The application to software architecture and design here is relatively straightforward, I think. But just as important is the recognition that it applies to our organizational design as well!