I had a team once implement the MediatR pattern for a < 5k LoC codebase (I'm guessing at its size but it was made larger due to the overhead of the MediatR pattern).
When I asked them to remove it, it became a political fight that went to the VP because they were convinced that sort of flexibility was a good idea. Fast forward a year and they have a new technical leader and he thought I wanted that complexity until we had a conversation and when I mentioned I didn't like it he confessed to me he wanted to rip it all out.
People value the wrong thing too often.
Believing flexibility is needed still suggests a lack of understanding.
This leads to a certain kind of decoupling, although with a higher tolerance for coupling that can kept in check by static analysis.
Values are those things that help guide you in the face of imperfect information. Not having a crystal ball that can predict the future perfectly means you have imperfect information.
To prioritize flexibility means that one lacks the understanding required to even build a misguided confidence.
At which point your description of a lack of understanding applies, hence my comment.
But, for contemporary software developers in general, I'd guess more often it's either resume-driven development (e.g., add the big complex new framework keyword to your resume) or not yet having enough experience to know what complexity is worthwhile for a situation.