Qualquer resposta direta será extrema. Claramente, há casos em que o prazo é tão apertado que você deve usar código feio e há casos em que o código é tão feio que vale a pena perder o prazo para melhorá-lo. O que você precisa é de métodos para julgar em que você está, e talvez métodos para definir prazos realistas que permitam tempo para escrever um código melhor.
Não salve a limpeza para mais tarde. A menos que você habitualmente tenha períodos sem nada a fazer além de refatorar, não há "mais tarde" em que, de alguma forma, se torne mais prioritário arrumar o código do que é agora. A rotina é "vermelho, verde, refatorar", não "vermelho, verde, fazer algo completamente diferente por duas semanas, refatorar". Realisticamente, você não mudará o código até a próxima vez que o revisar por algum outro motivo, e provavelmente também estará dentro de um prazo. Suas opções reais são para corrigi-lo agora ou deixá-lo.
É claro que o código com estilo é melhor que o código com estilo incorreto, supondo que você planeje lê-lo novamente. Se você planeja nunca mais lê-lo novamente, não o arrume . Envie a primeira coisa que passa nos testes. Mas esse é um cenário bastante raro, para a maioria dos programadores isso acontece quase nunca. Ignorando esse caso, somente você tem os detalhes do seu caso real para avaliar quanto custa para consertar versus quanto custa (em manutenção futura aumentada) para não consertá-lo.
Há certas coisas que não são mais difíceis de corrigir no momento em que o código requer manutenção, do que devem ser corrigidas agora. Na verdade, isso não beneficia muito você a corrigir agora. Os mais óbvios são triviais para corrigir (erros de espaço em branco e similares) e, portanto, é difícil imaginar que você tenha tempo para fazer esta pergunta, mas não para corrigi-la ;-) Para aqueles que não são triviais e são desse tipo, então OK , você tem um código que não é ideal, mas deve ser pragmático. Funciona e você está dentro de um prazo. Use-o.
Há certas coisas que são consideravelmente mais fáceis de corrigir agora do que serão mais tarde quando (a) não estiverem tão frescas na mente de todos; (b) outras coisas foram escritas que dependem ou imitam. Eles são muito mais valiosos para corrigir agora, portanto, priorize-os. Se você não tiver tempo nos prazos para corrigi-los, precisará pressionar o máximo possível por prazos mais longos, porque está criando dívidas em sua base de código que provavelmente terá que pagar na próxima visita o código.
O método preferido de correção de código é através de um processo de revisão. Comente os problemas que você tem com ele e envie-o de volta ao júnior para mudar . Você pode dar exemplos do que você quer dizer e deixar o junior para encontrar todos os casos no código ao qual eles se aplicam, mas não basta terminar o código para eles. Se o fizer, não lhes dará meios para melhorar.
Você deve escrever problemas comuns em um guia de estilo que diga "não faça isso, faça isso" e explique o porquê. Em última análise, é permitido que o motivo seja "para tornar nosso código esteticamente consistente", mas se você não estiver preparado para escrever suas regras com alguma justificativa, provavelmente não deverá aplicá-las. Apenas deixe cada programador livre para escolher.
Por fim, cuidado com a tendência de ajustar as coisas indefinidamente. Os retornos diminuem e você precisa aprender com a experiência em que eles ainda são bons. É absolutamente essencial que você forme uma idéia realista do que é bom o suficiente, ou então não poderá ter essa negociação na qual se assegura de que seus prazos lhe dêem tempo para criar código "suficientemente bom". Gaste seu tempo com coisas que não são boas o suficiente.