It's the definition of simple that's the problem. For any definition of simplicity you might have, someone has an equal and opposite definition.

Take these two alternatives:

  class UserService {
    PostgresDatabase db;
  }

  class UserService {
    IDatabase db;
  }

There are some coworkers who will veto the first example for being too complex, because it brings Postgres (and its state and connections and exceptions and mappings) into the scope of what otherwise could have been a service concerning Users.

There are some coworkers who will veto the second example for being too complex, because Postgres is all you use for now, and if you really need to use a second database, you can change the code then (YAGNI). Also the Interface gives you a pointless indirection that breaks IntelliSense so you can't just 'click-through' to follow the code flow.

I recently had a performance review at a FAANG. One engineer on my team has spent the past 3 years working on a complex infrastructure migration which involved about 20 engineers. The migration was completed last year and saved the company some opex costs.

I on the other hand spent 3 weeks optimizing our core service and reduced 2x the opex costs of the large complex 3 year migration.

In my yearly review my manager acknowledged my impact, but said I need to solve more complex problems to get to Staff Engineer. I protested saying that my 3 weeks of work had a larger impact than 20 engineers over 3 years, but he told me that is just how it works.