As multiple folks have mentioned before, focusing solely on mechanical code coverage will most often yield a bad unit test setup.  But then again that's true of pretty much true of any principle or metric being used without considering what the metric tells you or intended for. I prefer a combination of code coverage and functional use case coverage , with additional focus or emphasis on heaviliy used areas if you have detailed usage metrics.  That tends to yield a fairly decent testing package without requiring the mother of all test packages or other anti-patterns.

That said - I can't say I agree with not setting up tests for code branches that "aren't being used" at all. It's one thing if the code cannot ever be accessed or triggered unless someone hacks the application, but if the code is a feature on the UI or can easily be accessed, then it's getting a test.  Besides - we tend to develop using TDD, so tests are built out when new functionality is introduced (i.e. before you know it actually will be used).  If you're deploying code, you had better know this won't break things so not setting up basic testing frankly is not an option.

By the way I do agree with campaigning to remove features if no one plans to use them, but until it IS removed, what that code does and how it operates is on us.