What you really learn over time and it’s more useful, is to think along these lines: don’t try to solve problems that don’t exist yet.
This is a mantraic, cool headline but useless. The article doesn't develop it properly either in my opinion.
It is best to prepare for problems which don't exist yet. You don't need to solve them, but design with the expectation they may arise. Failure to do so leads to tech debt.
― Dijkstra
And then, there's people who do "resume-driven development" and push for more complexity in their workplace so that they can list real-life work experience for the next door to open. I know someone who made a tool that just installs Java JDK + IDE + DBearer using Rust, so that he can claim that he used Rust in the previous company he worked for.
I generally think we're more obsessed with being perceived as engineers than actually do engineering.
Unfortunately, simplicity is complicated. The median engineer in industry is not a reliable judge of which of two designs is less complex.
Further, "simplicity" as an argument has become something people can parrot. So now it's a knee-jerk fallback when a coworker challenges them about the approach they are taking. They quickly say "This is simpler" in response to a much longer, more sincere, and more correct argument. Ideally the team leader would help suss out what's going on, but increasingly the team lead is a less than competent manager, and simplicity is too complicated a topic for them to give a reliable signal. They prefer not to ruffle feathers and let whoever is doing the work make the call; the team bears the complexity.