It's a difficult feature to design. The problem is it can't work like a simple logical OR as it needs to involve picking, which is a unique aspect to event sheets.
You can illustrate the difficulty with a counterexample. Suppose it did just work like a boolean test, and then you set up this event:
+ A overlaps B
+ OR: spacebar is down
-> destroy A
Now if you press spacebar, even A which are not overlapping B get destroyed. But this violates a key principle of events that actions only run on the instances which met the event's conditions.
This would mean running the OR block like this:
1. Test "A overlaps B". None are true and so none of either A or B are picked. Usually this means it doesn't run the event, but it's an OR block, so other conditions might be true, so keep checking them.
2. Test "spacebar is down". If this is true then the actions can be run. However "A overlaps B" just unpicked everything. Should it then go and pick them all?
If it worked like this I think you'd get equally-confused threads where people say "why does this OR block affect things that did not meet the condition?" I can't remember exactly as this was originally designed years ago, but I think this was originally the case, it confused people, and so the design was changed early on, but the new design still trips people up.
Because of picking, I'm not sure there's any obvious or intuitive way to design OR blocks. Perhaps the naming is misleading and they should be called something else like "ANY" blocks, so people don't approach it with the mindset of a logical OR. That does also better match how they work, as an OR block really means "run all the conditions, and then run the actions if any condition was true".