You're the one missing the point. Don't write the ugly hack in the first place, and you'll find that that code can be written faster, debugged much faster, and won't be an albatross in the long term. I also find that the crappier the code, the buggier it is and the more support requests are generated (the Pareto principle definitely applies here) - which sucks developer time away from more important things and compounds your problems.
This is something that I've seen several times, and in every case the people involved severely underestimated the time suck of crappy code. "It's not that bad" often means that the developer is spending 50% or more of their time working around deficiencies.
ugly hacks, assuming decent programmers, is usually a result of not knowing exactly what you are writing when you first start. This is common, and often it's not worth refactoring it as in the example I gave.
You ignored all the points in my last comment. Let me be more explicit. Bad code is only an albatross if you have to work with it again. What I'm arguing is that it's usually wiser to leave it as it is until the next time you have to work on it, then fix it. It's only an albatross if you don't fix it, and you only save time by fixing it if you actually have to touch the code again. So wait until you're certain that you're going to have to touch the code again, and fix it when you touch the code again, and not before that.
How often have you written a piece of code and known ahead of time that you'd never have to touch it again? Even throw-away code, like data migrations, often gets revisited several times while you're writing it.
So why is your supposedly decent programmer writing crappy code and assuming that they'll never have to touch it again?
Which is my original point. Traditionally the expectation is crappy-fast-and-cheap vs. perfect-slow-and-expensive, but that rarely holds. Instead it's usually the crappy code that ends up being slow to write and expensive, stuck in endless code and bugfix cycles trying to get it right.
This is something that I've seen several times, and in every case the people involved severely underestimated the time suck of crappy code. "It's not that bad" often means that the developer is spending 50% or more of their time working around deficiencies.