Quase tudo pode ser analisado em termos de custos e benefícios, e acho que isso se aplica aqui.
Os benefícios óbvios da primeira opção são que ela minimiza o trabalho a curto prazo e as chances de quebrar algo reescrevendo o código de trabalho. O custo óbvio é que ele introduz inconsistência na base de código. Quando você está executando alguma operação X, isso é feito de uma maneira em algumas partes do código, e de uma maneira diferente em uma parte diferente do código.
Para a segunda abordagem, você já notou o benefício óbvio: consistência. O custo óbvio é que você precisa se empenhar para trabalhar de maneiras que, de outra forma, teria abandonado anos atrás, e o código permanece sempre ilegível.
Para a terceira abordagem, o custo óbvio é simplesmente ter que fazer muito mais trabalho. Um custo menos óbvio é que você pode quebrar as coisas que estavam funcionando. Isso é particularmente provável se (como geralmente acontece) o código antigo tiver testes inadequados para garantir que ele continue funcionando corretamente. O benefício óbvio é que (supondo que você faça isso com êxito) você tenha um código novo e brilhante. Junto com o uso de novas construções de linguagem, você tem a chance de refatorar a base de código, que quase sempre dará melhorias em si mesma, mesmo se você ainda usou a linguagem exatamente como ela existia quando foi escrita - adicione novas construções que tornem o trabalho mais fácil, e pode muito bem ser uma grande vitória.
Um outro ponto importante: no momento, parece que este módulo teve manutenção mínima por um longo tempo (mesmo que o projeto como um todo esteja sendo mantido). Isso tende a indicar que é muito bem escrito e relativamente livre de erros - caso contrário, provavelmente teria sofrido mais manutenção nesse ínterim.
Isso leva a outra pergunta: qual é a fonte da mudança que você está fazendo agora? Se você estiver corrigindo um pequeno bug em um módulo que, no geral, ainda atende bem a seus requisitos, isso tenderia a indicar que o tempo e o esforço em refatorar todo o módulo provavelmente serão desperdiçados em grande parte - no momento em que alguém precisar mexer com novamente, eles podem estar aproximadamente na mesma posição em que você está agora, mantendo um código que não atende às expectativas "modernas".
Também é possível, no entanto, que os requisitos tenham mudado e você esteja trabalhando no código para atender a esses novos requisitos. Nesse caso, é bem provável que suas primeiras tentativas não atendam aos requisitos atuais. Há também uma chance substancialmente maior de que os requisitos passem por algumas rodadas de revisão antes de se estabilizarem novamente. Isso significa que é muito mais provável que você esteja fazendo um trabalho significativo neste módulo no (relativamente) curto prazo, e muito mais provável de fazer alterações no restante do módulo, não apenas na área que você conhece corretamente agora. Nesse caso, é muito mais provável que refatorar todo o módulo tenha benefícios tangíveis e de curto prazo que justifiquem o trabalho extra.
Se os requisitos foram alterados, você também pode precisar analisar que tipo de mudança está envolvida e o que está motivando essa mudança. Por exemplo, vamos supor que você estava modificando o Git para substituir o uso do SHA-1 pelo SHA-256. Essa é uma alteração nos requisitos, mas o escopo é claramente definido e bastante restrito. Depois de armazenar e usar o SHA-256 corretamente, é improvável que você encontre outras alterações que afetem o restante da base de código.
Por outro lado, mesmo quando pequeno e discreto, uma alteração na interface do usuário tende a aumentar, então o que começou como "adicionar uma nova caixa de seleção a essa tela" termina mais como: "altere essa interface do usuário fixa para oferecer suporte a modelos definidos pelo usuário, campos personalizados, esquemas de cores personalizados etc. "
Para o exemplo anterior, provavelmente faz mais sentido minimizar as alterações e errar no lado da consistência. Para este último, é muito mais provável que a refatoração completa seja recompensada.