Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.