My favorite insight on clean code is that the metaphor of "technical debt" is incredibly deep. It's not just "we skipped X hours of cleanup" - you can meaningfully discuss the purpose and size of the loan, interest rate, payment plan, and more.
From that viewpoint, there are basically three happy cases for paying tech debt. You can treat it like a paid-off credit card, releasing code today and then paying off the principal tomorrow before you incur any interest. You can use it like a home loan, accepting that you can afford long-term interest more easily than committing all the time upfront. Or you can use it almost literally as a business loan, releasing something ugly which makes the money you'll need for services/salaries/etc to pay off the debt.
In practice, most companies accrue tech debt like credit card debt or back taxes. Either they pay a fortune in interest (i.e. maintenance, dev ramp-up time, and slowed development) so they can't afford to work down the principal, or they ignore the entire problem until it grows way more expensive.
The upside is that there's not much longterm cost to declare tech bankruptcy. If something can limp along until it's replaced, all the work you've been putting off can be skipped completely. Hence the godawful state of videogame code: people aren't necessarily worse about hacking things together, but they're usually coding with a clear ship date in mind, so they don't worry so much about feature requests, training new devs, or anything else long-term.
(Sometimes this blows up, like when a studio wants to make a sequel to a hit game and discovers everything they've built is unusable. And post-release patching has raised the lifespan of game code a lot from the days when you pressed a master CD and walked away. But all of that is speculative: if you don't ship, or don't sell well, the code is dead anyway.)