Ao longo do tempo você vai desenvolver seu próprio critério para isso e saberá quando é o melhor momento para aplicar determinado contexto.

As demandas de problemas já conhecidos são chances de pegar o que já funciona e tentar fazer da melhor forma possível. Caso seja algo novo, irá focar na funcionalidade para depois gastar tempo em cosméticos. É mais ou menos essa linha que venho seguindo. Para mim não adianta perder tempo deixando algo bonito se não tenho confiança de que tá funcionando.

Sobre deixar o código "melhor"; ou "bonito"; ou "manutenível". Você poderá sempre recorrer aos patriacas da refatoração e boas práticas como o Martin Fowler ou Robert Martin, mas ainda vai ter que passar pelo seu próprio crivo, ou até de um revisor, do que é o melhor código para determinada base de código. Se estiver trabalhando em código legado ainda terá o crivo da confiabilidade de não ter adicionado um bug ao código.

Uma dica é sempre que possível criar seus códigos já pensando em testes unitários. Isso tornará o código mais acessível do ponto de vista da utilização e gerenciamento de estado. E esses detalhes farão a manutenção ficar muito mais agradável.