One way to grasp it would be with concrete examples.
So an expression like:
"is a man" OR "is a man with a sister" (i.e. A = is a man and B = has a sister)
In this expression, if you're a man, it doesn't really matter whether you have a sister or not, you are to be counted.
or perhaps closer to a program, in an answer to "which words should we select?":
"words that start with W" OR "words that start with W and end with S"
You can see that the second condition identifies at most a subset of the first and is therefore redundant (and can safely be lopped off).
In code, you would simplify an expression like:
if s.startswith("W") or (s.startswith("W") and s.endswith("S"))
This might be why it's handy to know as a computer scientist. Conditional expressions have a tendency to become complex (and therefore difficult to reason about). Being able to simplify them safely is often a good refactoring move.
Another way to grasp it would be visually, with a Venn diagram with A and B overlapping circles. In that case, A AND B would be their intersection (the overlapping part) and the expression A OR (A AND B) would mean all points inside A or inside the intersection. Since the intersection is by definition all within A, specifying the (A AND B) intersection as an alternative is redundant.