In search for the component
Components help us structure and organize our code in a logical way. We use them as easily replaceable building blocks and we have developed the thinking that anything that isn't build by such components won't scale well. To reduce our costs we have learned to assemble the desired functionality from inexpensive, easily available parts. But there is a danger that by reusing existing components we constrain our thinking in certain ways that stay in the way of embedding our own thinking into the project. Instead, we spend the majority of our energy trying to understand someone else's thinking, when we have no access to their domain knowledge that influenced the decisions we see.
Components help to make our projects more manageable. The nesting levels in the code help us to quickly find the parts that need to change. In many cases, instead of using the find function, we can rely on the logical ordering of the code to arrive to the component we want. But the more components we have, the less effective this becomes. With hundreds of them, we would need to have a separate list that enables us to jump to the place where they were defined. Branching and deep nesting can create complex and hard to follow structures where we can easily lose ourselves. But reducing the number of levels would mean to extract even more components. Sometimes it can be easier to think hierarchically rather than sequentially and an attempt to convert between the two may create more problems than it solves.
It is then not a good idea to try and bring every existing technology under a common denominator for improved consistency within a single system.