I think R0J0 alluded to some interesting difficulties. FWIW OR blocks are extremely complicated internally which makes them difficult to begin with. But when you add picking, things start to get less intuitive. For example take this gotcha with the existing OR blocks:
+ Sprite instance variable 'health' < 0
+ Spacebar is down
-> Add 10 to score
-> Sprite: spawn 'Explosion'
People run in to this counterintuitive issue where the event can run with no instances picked. Suppose you press space and no sprite instances have health < 0. The event runs because the space bar condition was true and the score increments - but zero instances of Sprite are picked because they all failed the condition - and no explosions are spawned. So it looks like the "Spawn" action is broken, when actually everything's working as designed. There is nowhere else in the event system events can run with zero instances picked, and this kind of quirk occasionally trips up users. In other words, once picking gets involved, it's not as simple as boolean algebra any more. I am sure this suggestion would uncover similar confusing and difficult cases.
I think the bigger problem is that even with this feature, it's still limited. Currently you can do events of the form A AND B AND C, and if you use an OR block, you can do A OR B OR C. If you add a sub-event that is also an OR block, you can make events of the form (A OR B) AND (C OR D). This suggestion allows for (A AND B) OR (C AND D). The next logical step is to allow more complex forms, for example (A OR (B AND C)) OR D, etc. To do that you'd really need "open parenthesis" and "close parenthesis" conditions, which I really think is a step too far. I think expressions are better suited to that, especially the "pick by evaluate" condition which also allows for picking instances by arbitrary expressions.
Basically given the complexity of this, the weird edge cases, and the unsuitability of taking it further, I think we have an OK tradeoff as it is.