Sounds like dilemma: https://en.wikipedia.org/wiki/Dilemma#Use_in_logic
You'd get much more value from phrasing it as
((p implies r) and (q implies r)) iff ((p or q) implies r).
Certain concepts like the law of excluded middle (either A or not A must hold), and proofs by contradiction that are common in math, simply don't exist in programming. That's because programming is based on constructive logic / constructive math foundation.
Learning the basics of logic can be beneficial for a programmer tho, and the connection with functional programming is especially high.
Given
a implies p
b implies p
a or b
But notice that if you have
a implies p
b implies p
c implies p
a or b or c
This is most of the point I'm making -- there is no context where the brittle, overspecified version is useful but the more general version isn't. But there are lots of contexts where the overspecified version is useless.
And again, it's not a different rule. Brittle "disjunction elimination" is a special case of the rule I state. Similarly, the Pythagorean Theorem is a special case of the Law of Cosines, not a different rule.
It gets worse, though, because where the Pythagorean Theorem is simpler to state than the Law of Cosines, brittle disjunction elimination is more complex to state than the more general result is.
Think about exportation. We say:
(a implies (b implies p)) iff ((a and b) implies p)
((a implies (b implies p)) and (a and b)) implies p