MikeD, you are also warned: if anything, attack the argument, not the person, and your post was blatant flamebait. There is no need for this.
In regards to the original problem:
For Each Sprite
Sprite is on layer 2
: Rotate sprite
This is now fixed, for what it's worth, but note it has identical effect to this:
Sprite is on layer 2
: Rotate sprite
This event alone will check every Sprite, one by one, and pick the ones on layer 2. You don't need a For Each; Construct does this automatically.
As for your other ideas - some of them don't seem quite right to me. Do you want to force every event to have a trigger (an "on" event) in it? If so, I would see that more as a limitation than an improvement. It'd make it difficult to do something while the left mouse button is down, for example.
In the existing event structure, your fishing analogy could be like so, with subevents:
On line tugged
: Pull up line
: Inspect fish
----> Fish is good
----: Store fish
----> Fish is bad (or ELSE)
----: Throw fish back
Therefore, I think events can easily represent real-world situations and logic as it is. You may also be interested in Condition Aliasing in the function object (read about it here) which would allow you to literally make a condition that says "Fish is good", as opposed to comparing some number or something less obvious.
Also, you mention you have difficulty with instances created at runtime. What specific problem are you having? You can use instances created at runtime in exactly the same way as ones which are created in the layout editor.