Like financial debt, technical debt can only be ignored for so long. Eventually, badly-serviced code gets mucked up to the point where changes are prohibitively difficult.
The normal response I see to this is for companies to hire new talent to come in and write a parallel v2.0 while the old talent nurses v1.0. v2.0 takes 6-12 months to develop, and then it works OK for a while, but since management's refusal to prioritize technical quality is really the crux of the issue, v2.0 eventually grinds to a halt as well, and the cycle repeats for a v3.0.
So they're still forced to hire to someone to help them resolve the friction caused by technical debt, and this method comes at a much greater cost than hiring someone competent and giving them the necessary resources/allowances (which, yes, includes an adequate number of programmers) in the first place. That allows the same codebase to remain maintainable (or even just salvageable) and be used long-term, without really having to rewrite the thing and throw all of the knowledge surrounding corner cases, etc., out the window for v+1.
The normal response I see to this is for companies to hire new talent to come in and write a parallel v2.0 while the old talent nurses v1.0. v2.0 takes 6-12 months to develop, and then it works OK for a while, but since management's refusal to prioritize technical quality is really the crux of the issue, v2.0 eventually grinds to a halt as well, and the cycle repeats for a v3.0.
So they're still forced to hire to someone to help them resolve the friction caused by technical debt, and this method comes at a much greater cost than hiring someone competent and giving them the necessary resources/allowances (which, yes, includes an adequate number of programmers) in the first place. That allows the same codebase to remain maintainable (or even just salvageable) and be used long-term, without really having to rewrite the thing and throw all of the knowledge surrounding corner cases, etc., out the window for v+1.