Say you have a function/method.
Say you have a number of preconditions that need to be met in that function/method before proceeding deeper into the sub's logic.
Devel::Cover points out which unexercised paths among those preconditions need tests written for them. You write those test, so that the preconditions are 100% tested.
Deeper inside the function.method, Devel::Cover shows you other untested paths.

Looking at these, it quickly becomes apparent that, _if_ the preconditions have been met, and therefore you have progressed to one of these untested code branches, that it is not possible to specify a set of parameters to that function/method that pass the preconditions and progress down the untested path - therefore the untested branch is redundant - it can never be exercised.

Redundancy isn't bad in the least bit. Since computers, math and all things logical are "incomplete" (google "halting problem turing godel"). Its impossible to remove all bugs, and (this is my belief) that there is a direct correlation between complexity and the bugginess (gotta love those scientific terms). Since there will always be bugs, redundancy is used to "detect" and possibly "ignore" bugs. Critical systems, such as those used on the F-16, have numerous redundancy that are checked against each other to determine the "correct" results. Of coarse even with highly redundant systems, it is possibly that a bug will result in a uniform false result.

However, what is considered "critical" when flying faster than sound is quickly becomes "overkill" when running a perl script. In the end you have to decide just how important it is that the script absolutely runs.

Actually, redundancy is bad. Redundancy is, in fact, a great evil. Redundancy hinders the propagation of changes.

Redundancy and failover systems can be good in hardware, but that scenario is not comparable to redundancy in code on any level.

Makeshifts last the longest.