> Yes but... in today's software culture, the fastest cleanest and least complex solution is very rarely appreciated or even tolerated.
Funny how this sentiment is as old as "kids these days".
There are reasons why complex solutions are needed. These reasons are so much valid, that certain areas legally mandate the complexity. While majority of those reasons are safety related, one of the aspects behind safety is reliability and maintainability.
Usually (!), there is a balance. What is the least amount of training you have to supply the person doing maintenance that they could grasp all the assumptions, constraints and links with other components to successfully work on a component? The more complex the system, the less complex an individual component, in a way it interacts with the rest of the system.
For example electrical power supply units. Some fields require PSUs to have galvanic isolation, which makes them much more complex than $2 aliexpress part. However, galvanic isolation means that there are e.g. no weird, parasitic interactions over grounding - it just provides power like a battery would. Swapping a battery with a medical grade PSU would not introduce hidden interactions with the rest of the world.
Likewise, in a software system, a single component becomes (or at least can become. Complexity does not necessarily yield that, but complexity is required to provide this) more isolated, easier to work on alone without introducing breaking changes in different subsystems.
Do you need complexity? Not necessarily. Maybe the project is small and relatively short lived. Maybe you are thrown into a decade old project with requirements and teams having been changed several times in that timeframe. Component isolation backed by complexity would probably be highly appreciated.