If I could get a pound for every time someone has invoked simplicity (or its antonym: complexity) to justify a short-sighted or just plain wrong decision, I would probably have filed for early retirement quite a few years ago (yeah, hyperbole!).
This fake invocation of simplicity usually manifests in the desire of an individual or a team to take a shortcut, to do less work to achieve a seemingly equivalent outcome than a longer, more industrious route, without doing a proper analysis of the tradeoffs.
"Ah it's simpler if we just do everything in a single HTTP call". Is it? Well, by the mere use of the word "everything" we are acknowledging this endpoint does more than one thing. If something fails in the middle, are the other actions idempotent? How much costly would be to make two, three calls? What's the user experience we are trying to model? Aren't we conflating multiple different things into one?
"I know this path it's critical, but adding an end-to-end test would introduce massive complexity to the test suite". The question is, is it worth it? Can we afford a regression in this crucial routine? What errors can happen here? Can we quantify the risk? What would be the business cost of them versus introducing the code for testing it?
"I think we can use this concept to model this other one since they are quite similar". Similar is not good enough. Are they really similar? What are the ways in which they differ? How can those differences affect other processes and future ones? Aren't we assuming those differences we are collapsing will never matter? Can conflating both things lead to confusion, both now or in the future?
"It's simpler if the callers handle this case, we want to keep this service's complexity low". Oh really? Is this the proper way of solving a problem, or is it just a way of pushing it further downstream? How many callers would need to duplicate work for the sake of this service's simplicity? Is the responsibility of the consumers to handle this? What's the cost of doing it once versus for each caller? Can the case be made this is a responsibility of the service?
"It's simpler if we solve for 90% of cases, and worry about the other case later". Well that depends. Is that 10% going to need a full rewrite? Can we make provisions in the 90% solution so that covering the 10% is not a big change? Do we know what that change might look like? Do we have a plan to evolve the approach? Can we afford spending more time in a proper analysis?
"It's simpler to write the code this way". It may be, but is it easier to read it? You write code only once, but you read it far more many times. Is it optimised for readability? Is it easy to understand? Is it easy to change? Is it easy to maintain?
"Let's just put it all in one place: it's less code to maintain." Oh is it? Is really fewer files less complexity? How coupled is this code? What are the ways in which this code can change? Is it going to be costly to decouple it should we need to do so in the future?
I could think of countless of similar examples that I've heard during my career (and probably you too!). What all these phrases have in common is that they trade true simplicity for its cheap, shallow and deceptive cousin: convenience. They invoke an illusion of simplicity, when in reality they just want to do the more convenient thing now, without much thought about tomorrow.
People do this for various reasons. First, they might do it because they don't know better: and that's okay. The important part is that when faced with the tradeoff analysis, you can earnestly recognise them and change course, instead of romantically or stubbornly fixate to an approach that is destined to be suboptimal.
Another reason people do this is because they are constrained in time. But here is where our call as professionals should be a strong and emphatic no, if we have strong reasons to mark the approach not only as suboptimal, but even detrimental to the long-term health of the codebase or of the business. This, of course, after we have performed the proper cost benefit analysis. There are legitimate cases where speed needs to trump over quality, especially if you work in a regulated environment.
Third, people do this because they are lazy. They might be lazy because they are not motivated to learn new things, or because they are not motivated to take the time to understand the tradeoffs involved in their decisions, or simply because they dont' want to do more work than in their view is necessary. I've come to the conclusion that the only way to deal with these people is that you keep pushing them to reconsider and even block or delay them if you have that power. Lazy people hate being inconvenienced.
Overall, it amounts to seeking and demanding excellence: both from yourself first and then from your coworkers.
However, more than understanding why people do these things, we need to understand the problem and the proposed solution. Do your job well and relentlessly evaluate tradeoffs, alternatives, and force people to make compelling cases for their apparently simpler solution. Never, ever accept a plain "is simpler" or "is more complex" as an argument, without a clear explanation of the why is simpler and complex, and compared to what. Unmask the convenience around you, until you are left only with true simplicity.
And, what is true simplicity, you might ask? Well, is the art of making what is by nature complex, easy to grasp, change and manage. True simplicity may be doing more HTTP requests, so error paths stay clear and boundaries are maintained, so they can be composed or decomposed at will later. True simplicity may be adding that end-to-end test that will save the business tons of money by preventing an incident instead of wasting resources in complex investigations and mitigation efforts. It may very well be separating two concepts instead of conflating them, even if that leads to more work now but enables them to evolve independently without breaking assumptions in the future. It may very well be to bring more code and responsibility to your service, so your callers don't have to do the heavy lifting and work is not duplicated. It may be writing a bit more code and investigate a bit further to ensure that 10% in the future doesn't need a full rewrite. It might actually mean to do more now, so you and other people can do less tomorrow. That's true simplicity.