It's probably been stated before by others, but I've recently arrived at the conclusion that engineers like solving hard problems. More importantly, I've come to the conclusion that in the absence of difficult problems, they will invent them.
Currently, I work in an organization where our technology stack consists almost exclusively of APIs. We interact with 3rd party APIs, we provide internal APIs, and also build consumers of those APIs. All of that, is to say, that we basically transport and shuffle data. We don't have any, really, truly, difficult problems in need of solving.
In the absence of difficult problems, I've noticed that some of the other software engineers will "invent" problems. For example, I've had instances where I've asked another team to implement something on their API exposing a key piece of data that my team needed. In response, I got something to the effect of, "We'd love to, but we're busy rewriting everything from scratch."
Exposing a new piece of data I needed, while important, wasn't a fun challenge. So, the team proceeded to rewrite everything on a whim, possibly because of some blog post they'd read, or new paradigm they'd found, or maybe even just a linter showed them their code wasn't "perfect."
This plays into part of the reason why Good, Fast, and Cheap is such a difficult balance. Engineers and developers always want to solve the hard problems. They will often invent new problems and compromise the fast and cheap aspects of a given project.
Shuffling data around isn't sexy. It's usually not fun, and it's rarely challenging. In contrast, auto balancing and rebuilding a tree structure using both nested sets and adjacency is a quite difficult problem. However, those problems are few and far between in a world where data is increasingly the primary commodity.