You're trying to get a release out the door. QA finds a problem that you can solve in 30 seconds with less than ten lines of code -- but it would tightly couple the module to something else, or expose implementation details of the object to all and sundry, or otherwise violate what might be considered to be principles of good design. Because of time pressure (or maybe because you're afraid of introducing uncertainty by making a larger change), you hold your nose and make the change, making a note on the to-do list that you should fix that "right" when things calm down. 

But they never really calm down, do they?....

The big difference between this and DoTheSimplestThingThatCouldPossiblyWork is that the change is compromising, rather than serving, a longer-term goal of more readable/less tightly coupled/"better" design. Instead, you're backsliding the design, perhaps in the service of other goals. (There ''are'' other goals in the world. Product has to ship, after all.)

The problem here is not a single "smallest change", viewed in isolation. It's the cumulative effect of such changes, left unchecked. It's best to recognize such things for what they are -- a compromise between expediency and long-term maintainability. To keep the code maintainable long-term, you ''will'' have to refactor at least some of these changes so they're done "the right way."

Also known as KeyholeMaintenance.  See BoiledFrogs for a metaphorical description of the more general phenomenon.