If product concepts are not reflected in the code, programmers might implement features in ways that don't make sense in the product.

Dirty code incentivizes the business to invest in tangential revenue work rather than attacking core business problems.

Even with good automated test coverage, dirty code increases the risk of introducing regressions.

Wide or unclear dependencies reduce the quality of tests.

Dirty code hides real bugs.

Dirty code gets dirtier.

And his final thought:

"Well, what can I do about it?" First, try to pay attention to your code. After you finish writing some, ask yourself "Could I make this clearer?" Then ask your neighbor the same question.

Only if it is as trivial! Currently working on dirty code lingered over the past 10 years, and have no opportunity to fix it, due to the fact that the company has always been pushing for products and features first. Hacks can be fixed later -- well they never get fixed when you do not reserve your developers' time on refactoring.

Teams are messily structured that the management assumes "everyone should be able to work on anything". That throws any code ownership out of window. That leads to reduced motivation. When I don't get motivated to make code better -- even more dirty code gets produced.