Quando seu intestino está lhe dizendo que você provavelmente deveria refatorar, é provável que seus instintos lhe digam um pouco tarde que você adia algo importante por muito tempo.
Entendo "cheiros de código", refatoração de vermelho-verde e outros pensamentos, mas muitas vezes sinto que o melhor momento para refatorar não é a primeira vez que você escreve o código, mas a segunda ou terceira vez que você está usando o código e percebe que é realmente um problema e está em uso real.
Existem efetivamente dois níveis para refatoração. O primeiro são os problemas óbvios que aparecem quando você codifica pela primeira vez. Essas são as pequenas otimizações que custam muito pouco para você fazer com antecedência. Coisas como manter seus métodos e classes pequenos e aderir a DRY e SRP. Então você tem o estágio adicional de lidar com grandes falhas em seu design, que podem não ser imediatamente aparentes até que seu código tenha algumas milhas abaixo. É desse segundo nível que você está falando e, para garantir que a refatoração posterior não seja muito dispendiosa, é necessário que você já tenha escrito seu código de forma que o esforço que você imagina mais tarde seja mais fácil e menos dispendioso, o que significa fazer uma refatoração precoce.
Como Jeff mencionou em sua resposta, "tempo é dinheiro" , principalmente em empresas onde a carga de trabalho é alta e os riscos ainda mais altos. O tempo gasto no início para garantir que o código esteja no seu melhor estado possível é economizado mais tarde, ao provocar o que deveria ter sido uma refatoração fácil acaba sendo uma operação importante.
Ao escrever um software, cada momento gasto para melhorar seu código antecipadamente economiza tempo mais tarde, quando você realmente precisa dele. Quanto mais cedo você refatorar, mais claras serão as alterações posteriores. É como fazer um adiantamento em dólares de hoje contra futuras dívidas técnicas, que estarão em dólares inflacionados amanhã.
De qualquer forma, a refatoração não deve ser uma tarefa que você adia até um futuro misterioso, quando o software já está completo e estável, pois aumenta seus riscos mais tarde, quando as apostas são muito maiores e o produto muito mais difícil de mudar. A refatoração deve fazer parte de suas atividades diárias, e essa é a essência da filosofia Red-Green-Refactor que você mencionou.