I wonder if there was anything that works the same as Wait 0.0 but better... like CHANGE SHIP LOCATION or some other random command nobody would think of calling

uh... also it helps with show picture if you make the picture as small as possible... so if you have a CMS you should make the menu graphic tiny and specify x, y instead of making a screen-size graphic with a lot of transparency? Also, I remember Move Picture is faster than Show Picture probably because Show Picture makes a new buffer everytime it's called... or something. Only problem with this is the natural thing to move around would be the cursor and you might want that to show instantly instead of /sliding/ over, but I think if you set the transition time to 0.0 seconds it's instant

I think there was something else weird like .xyz pictures show faster than .png. But I really don't know. It'd probably be easy to design a stress test for that though

Also if you do the command "Break" or "End Loop" or whatever it's called, when not inside a loop already, it brings the event to an end no matter how many lines of code are left. It might help to know that when designing your events. Like hell, I dunno, in a CBS if an enemy's already dead none of the other events matter for attacking it because it's already been beaten, and you just end the event instantly. You can have a switch or variable that's off or zero until something happens to make it otherwise. Like so with the dead case, the switch is off by default stays off which signifies a miss

Don't let stuff happen until you need it. Like if you have a floor full of arrows, maybe only activate them just before you get there and deactivate after you pass. In Befuddle Quest 3 there's a map where it feels like the submitter left all the events on and running even though the player hadn't entered their rooms yet.

I've never had that much of an issue with lag in Rm2k3. The only time I ever got/get lags is if I played a game in non-full screen (without pushing F5 key to shorten the screen down to the original pixels size) with a bunch of events activated all over the place around my character's presence. And with that, it is a bitch to move around maps.

However, I have realized the usefulness of having Wait set to 0.0 instead of just 0.1. For example, it's easier to do place a Parallel Process Event to change the tint/color of a screen when I'm walking around a certain map. With Wait: 0.1s, right when the screen loaded in a new map, I still saw the same color on the screen as the previous, before changing to the specified one for that map. With Wait: 0.0s, it INSTANTLY changes colors right when it loads and you see your characters.

Don't let stuff happen until you need it. Like if you have a floor full of arrows, maybe only activate them just before you get there and deactivate after you pass. In Befuddle Quest 3 there's a map where it feels like the submitter left all the events on and running even though the player hadn't entered their rooms yet.

Might surprise you, but that's exactly how the map was coded, closing down all irrelevant parallel processes to the current segment of the map. It did have a lot of empty events for each arrow tile though, which might have added a little to the load as well (at least in my experience I mean to have noticed that a lot of empty events could cause some lag). Building upon that, you could also use the screen related coordinates to limit stuff like coordinate updates to that which is actually on screen, unless it collides with some other part of the code/system

Choice of looping method could be something to consider as well. label + go to label being the fastest, loop being the second fastest, and simple parallel process being the slowest, with the chance of things lagging being higher with the faster kinds.
And of course, if there is something which doesn't need to be updated all that often, you might wanna use more than just a 0.0 wait as well, leaving it for stuff which needs to be processed faster.

Just script your systems in loop cycles instead of using parallel processes and you should avoid lag almost entirely.

The reason why wait 0.0s works is because each wait 0.0 is actually 0.0167 of waiting.  If you want to, put two or three in there, because all the wait times do is have the parallel process or w/e you are using be executed less often.
If you want to, you can download the link in my sig, and you can open it up in rm2003 and see some of the ways I used to reduce lag; almost all of it is just executing events when they are needed, and at no other times.