Je partage son point de vue, il faut se poser les bonnes questions avant de se lancer dans un refactoring, surtout que le risque d'introduire de nouveaux bugs est important.

J'ajouterais également un autre point qui n'est pas mentionnée : tester unitairement une portion de code « mal écrite ». C'est subjectif, mais on tombe facilement sur du code qui n'est pas testable pour de multiples raisons comme l'usage abusif de variables globales, un énorme pavé de code, etc. Le refactoring peut se faire dans une logique d'améliorer la qualité logicielle en structurant mieux cette portion de code et en la testant. Vous, ou vos futurs collègues vous remercierons plus tard.

Un billet sur la pertinence du code coverage.