Schedule logic follows a transitive property of inequality. That is (from middle school), if A<=B and B<=C, then A<=C. Thus, if tasks 1, 2, and 3 are logically linked using FS relationships, then an FS relationship from task 1 to task 3 is implied; an explicit FS relationship between those two tasks is redundant. (Other relationship types can complicate things.)
As Vladimir says, redundant logic may (slightly) increase the number of mathematical operations needed to compute the schedule, but it does not decrease the mathematical validity of the schedule in any way (IMO). I see only one real argument against it: By introducing extraneous data, redundant logic may increase the difficulty of manual review, evaluation, and interpretation of the schedule data.
This is a concern that, I suppose, led to Acumen’s development of the algorithm for highlighting and removing redundant logic in P6 schedules. I don’t use that tool, and in general I don’t have issues with redundant logic in schedules that I prepare or review. I’m not convinced it was ever more than a minor nuisance before it started showing up on reports.
As a counter argument, substantial “redundant” logic may actually be necessary for those who use explicit crew ties together with progress override in P6. Since progress override essentially voids some logic ties in case of out-of-sequence progress, the previously “redundant” logic needs to step in and make an impact.
Zoltan, I believe that “waiting on non-essential predecessors” is an example of Bad Logic, or perhaps Preferential Logic that is no longer valid. Redundant logic is just that – redundant – it stays on the sideline and never enters the game. You'll never be waiting on it.
The more significant issue in construction (from my perspective anyway) is the opposite of redundant logic, Omitted Logic.