Except for the more or less trivial cases, your solutions for optimized speed and for optimized instruction count will look different. Sometimes very different. My approach is to first solve the puzzle, then copy the solution over to one of the other program tabs and optimize it for one of the goals. Always keep in mind that when you're optimizing for one of them, the other one doesn't matter at all. Don't try to subconsciously optimize both speed and count.

In order to count as success, your solution does not need to work for every input. This suprised me and I didn't make use for it, but if you succeed for over 50% of the cases, you're on the winning side.

First, don't overlook that the instruction count can be seen left to the actual instructions. No surprises here (unlike with the program speed).

Every if statement counts as a single instrucion, no matter how long and complicated it is. So do query as many things as useful in your if. Maybe you can spare something else by these, e.g. a second if?

There's seven billions of them, and they are not needed anymore anyway...! If the level instruction doesn't say anything else explictly, feel free to let every human except a last one die. Spare the instruction needed to spare a human.

This is not about recommending to try out what you can think of, even if it will probably fail - which I totally do. I'm thinking about the little errors. Dropping something although you haven't got anything to drop? Results in an ugly speech bubble and (probably) takes lots of time, right? Right, but we're not here to save time. Or bubbles. If it saves you a statement, like an if, just do it.

Contrary what you are told in real world programming - for a reason -, you might not want to initialize memory sometimes. You don't need to set it to five and count down to zero. It comes preinitialized to zero. So just add on it and compare it to five instead.

Something I might have been the only one to overlook: If you've got a position in memory, you don't need to walk there and afterwards pickup/giveto or whatever you want there. You can pass the memory directly to the pickup/giveto instruction. Gave me some headaches, so I'm writing this to make sure you will not get these.

Sometimes - but not always - the easiest way to do something is to do it yourself and not cooperate. So some optimizations might involve little to no help of most of the workers.

The time your program needs to run is harder to predict than the number of instructions. If it's not fast enough, just watching it run can help: What is happening too slow? Where are the humans waiting for something?

Contradictory to what I expected, in 7 Billion Humans these humans seem to move fast compared to the calculations. But then... it's humans doing the calculations, so I guess this is to be expected? You probably want to avoid too many calculations.

Now this is just like real world program optimizing: If you want a program to be fast, assure that the inner loops running most often are fast. Mind that you're not optimizing for count of instructions here, so an extra if instruction creating a very close loop (check - single instruction - jump - check again) might help your humans getting their work done faster.

Tired of all those game developers that cannot make use of your octa-core CPU? Show them! Problems are solved fastest when everybody, or almost everybody takes part. (Unfortunately, real world programming problems most times just aren't like this...)

If nothing else helps, "loop unrolling" might help. So if you know the number of times something will be done, you can write it down just as many times instead of having some if-jump construction. Tomorrow Corporation assured for Human Resource Machine that loop unrolling was never needed (except one obvious case as far as I remember) to meet the optimization requirements. I guess the same is true for 7 Billion Humans. Still, it might be a last resort. On the other hand... it is tedious! You might want to do it in an external editor with better copy/paste capabilities if you want to use this technique.

The most important speedup possibility in real programs is not about the small things, it's about changing the algorithm. Is the one you're using the fastest one? Is it at least close to the optimization goal?