Ok, I stumbled upon this problem: http://www.scirra.com/forum/viewtopic.php?f=3&t=7422
I made some tests and finally think I found the symptom. Maybe it helps the developers fixing it. It seems that an event with OR'ed conditions needs several (at least two) time units. I'm avoiding the word tick, because it doesn't need to be consecutive. The evaluation is only done correctly on the second time unit earliest. I think that's why you get the impression of OR working with a kind of randomness. Because, if you use it as a sub-event for example, it will most likely be tested only once and therefore give no correct result. But as soon as it has enough time units, it works correctly.
I've made a little cap to demonstrate it. All it does is generating a random number per click and testing if this number is in a certain range (for testing purposes in an elaborate way). The trick is, that there are three event groups called method 1 to 3, and you can switch through them. You will see, that method 1 works as expectable, method 2 does not work at all, and method 3 is "half-working". The last method is the reason for me to not talk about consecutive ticks. In this group the OR'ed event is a sub-event of a "every 3000 ms" event. If you look closely, you will see that the evaluation is incorrect the first time it is called, but correct on the second call, 3000 ms later.
or_issue.cap