Things certainly get overcomplicated! But when you encounter a system you think is overcomplicated, it's rarely as simple as that system's designer doing something wrong. More likely their hand was forced by context. Context and path dependence. It's an emergent phenomenon. Big companies have particular infrastructure, platforms, libraries, standards, expectations. Lots of it. Most of it reasonable when considered in its own context. But the way it interacts with any one systems designer's "simple" task can get weird.
At the benign end of the scale, you might need to use a more heavyweight tool than you'd like, because the company also has more intense problems and prefers to standardize on one tool. At the other end there's cruelty and farce. Elaborate workarounds for things that ought to be easy. Mind-bending debug sessions for what never should have been possible.
No one wants this to happen! The career incentive is to ship. We're tearing our hair out over it - honestly a big reason people have side projects is the catharsis of just doing everything the sane way. Overcomplication is a dysfunction that plagues engineering organizations. But the solutions are more subtle than "just say no" - it's about the quality of the company's platforms, degrees of NIH syndrome in the platform group, tradeoffs made between freedom and consistency in system design culture, wisdom and foresight in anticipating how different things will interact, etc.
Also underrated: at the time the company needed an X, Y was not around yet, so we adopted X. Yes everyone now agrees Y is better. We are migrating to it, but that takes time. No you can't have your own instance ahead of schedule. so you need to make do with X, even though it is worse and more complicated.