You should read that the CPU and GPU
work at the same time so if the screen takes longer to render than the events take to process, the events have no impact on performance.
As for making events run faster, generally just favour readability and whatever's easiest to maintain - you only need to optimise it once your game is running too slow. Before then, you cannot know if anything you are doing is making the slightest bit of difference.
As for your other questions:
[list:1ojrjbtc][*:1ojrjbtc]Some events are faster than others, but generally the difference is negligable - notable places people waste CPU time is nested 'For Each' loops, which with two nested levels with 1000 objects each, runs a million iterations every tick, etc. A single for each is usually fine though.[/*:m:1ojrjbtc]
[*:1ojrjbtc]Instead of having a lot of separate triggers it's faster - and more readable IMO - to have a series of subevents under one trigger. Subevents can be used similarly in other places to make events only checked when another event is true as opposed to all the time.[/*:m:1ojrjbtc]
[*:1ojrjbtc]Additional instances of objects cause more CPU load, because most conditions test all instances of an object. "Mouse is over X" has to iterate all instances of X for example, so the more X exist, the more processing there is to do. This generally only becomes noticable over an entire event sheet of events. You probably don't need to worry about memory load because rendering or CPU time will become a bottleneck sooner.[/*:m:1ojrjbtc][/list:u:1ojrjbtc]
In summary concentrate on making your game render quickly. 90% of the time the game is waiting for the screen to finish drawing rather than waiting for the events to finish processing before a tick is complete. Avoid intensive shader usage, and stick to PS 0.0 effects and plain old alpha-channeled sprites wherever possible. They're fast.