I think the biggest problem is that you potentially end up with:

a) infinite loop scenarios,
b) duplicated event triggers, and
c) a possible performance issue

For (a), consider:

Code:
ON *:BUFFERCHANGE:*:#channel:echo -a # just got updated


Works fine if the active window is not #channel, but infinite loop if it is. This is why mIRC [generally] doesn't trigger events that can be initiated via /command.

As for (b), you would have many cases where something like an ON JOIN triggered, and then a BUFFERCHANGE event fired for what is effectively the same event. It makes sense, in theory, for a BUFFERCHANGE event to override a JOIN event, but consider what happens when BUFFERCHANGE scripts start popping up: your ON ^JOIN script becomes obsolete and likely overridden by a BUFFERCHANGE event-- so now everybody starts moving their JOIN event processing into the BUFFERCHANGE event to ensure their theme related stuff doesn't get changed by another script. This causes confusion in implementation, and a general mess. This is all hypothetical, of course-- but it's plausible IMO.

Finally, (c): There's probably some kind of performance hit here too, just for firing an event everytime something updates in a window. Given that Khaled has already been struggling to maintain performance in the window buffer, I don't think it would be wise to slow it down again.

I'm not specifically against this request, I'm just offering my opinion of why it was likely deemed "difficult" by others.