In my experience, 95% of the time something appears unused or irrelevant, it is.
It's the other 5% that bites you in the ass.
I'm finding more and more that a total rewrite makes the most sense. This used to be taboo, but now, it often takes less resources than untying the Gordian knot of horribly evolved software.
And besides, someone should actually know what it does every 20 years or so.
I have seen production systems where the programmer will copy an existing method, rename it and modify it to "extend" the system. I have also seen programmers use their code browser as a revision control system that way. I have literally seen "lava flow code" where many, many programmers have been afraid to modify code, and it has been patched and program flow rerouted in a convoluted way that resembles hardening erupting lava.
The current system I am working on has a history of developers throwing away and rewriting subsystems. Not surprisingly, it has very understandable code.
I know the history of the system in my current job, because there are people from its inception over 12 years ago. They've told me about how subsystems have been rewritten. I've also witnessed it in my 3 years there. It's not always pretty. I've seen one subsystem rewritten 3 times by 3 different people who each thought they were smarter than the last guy, but then went on to make the same (very subtle, very difficult to understand) mistakes. The 4th time has stuck, however. The resulting code is much cleaner and is finally (relatively) trouble free. Its approach is significantly different from the last 3 attempts. Figure that!
I've also seen subsystems evolved in 2 or 3 iterations by the same developer, each iteration involving a rewrite.
So, I'd have to say my current shop is pretty good. They really should be doing more refactoring. They could be doing more incremental improvement and avoid the pain of complete rewrites. But at least they are wise enough to avoid pounding their heads against the wall of bad design indefinitely. (Or, to be fair, naive 1st drafts.)
A good comprehensive test suite helps here too. Cut the fat out, run the tests, if it passes you know that functionality wasn't needed and you can check it in. If it fails, take a look at the failing test and either cut the test out or revert your changes.
It's the other 5% that bites you in the ass.
I'm finding more and more that a total rewrite makes the most sense. This used to be taboo, but now, it often takes less resources than untying the Gordian knot of horribly evolved software.
And besides, someone should actually know what it does every 20 years or so.