I reckon that sometimes taking a piece of code and re-doing it from the ground up is the right decision. It can prevent unexpected problems further down the line.

In one of my previous roles, I had the (rather B.S. ) title of "Change Implementation Manager". What that really meant was that I was the gatekeeper between business departments and a very overworked and under-resourced IT department. It was a nightmare of cost-cutting combined with a sales department who thought that I business case meant throwing a big enough tantrum to get poorly scoped work done "because the customer wants it".

All that pressure meant that the poor IT guys had to take shortcuts. In particular, they'd point routines at bits of pre-existing code that did the job they wanted, rather than including the code in the discreet module they were working on (sorry if I'm not using the right terminology.... I was on the business side really, not an IT specialist at all !). Then, when the team on the other side of the world which really owned that code that had been hooked into made changes or decommissioned it, unexpected things would break all across the business.

Twice while I was there the company had failures so bad that they had to go back to pen and paper for several days. When the business finally folded, the official line was that it had been a ransomware attack so bad that it ate all their backups and they were unable to recover. But I suspect the reality may have been that their creaking code finally just gave up the ghost....