Strangely specifc questions about optimization? techniques

I'm pretty certain that making objects that are off screen invisible, is not going to improve performance - the display engine itself is going to ignore those objects anyway. All it would do is add the extra (very small) overhead of checking the position of each object.
With the second question it's really not going to make any difference . In general, it depends on the specific action and condition in question, as some take longer than others (for example, collision detection is slow; performing a complicated calculation is fairly fast; reading the value of a flag is super fast) - but in this case neither is using any measurable amount of processing power.

You're really worrying about the wrong things here. There are basically two things that restrict performance - fastloops, and displaying large amounts of objects. Do what you can to limit those, and then with everything else, you should just be focused on writing clear, easily readable code, which will help you avoid bugs etc.

I also have some advice. The debugger causes your game to lag while testing too. If you have objects in the debugger it will lag even more. If you want to realistically test your game's efficiency, close the debugger.

As far as I know negated conditions aren't any more taxing than standard conditions. Putting conditions higher or lower based solely on how expensive they are isn't exactly what you want to do, though. I address this below.

Now, as for advice... nothing that hasn't already been posted in other optimization threads, really:

-Use as few extensions as possible because most aren't compatible with all runtimes and some can be slow (but not all). I'm definitely not the one to ask about extension efficiency, outside of the Array object which is possibly the best extension there is (#fanboyism XD) and anything made by Nifflas since his extensions tend to be both multi-platform compatible and fast in my experience.

-When making conditions with multiple inserts, make sure you keep in mind Fusion reads these from top to bottom, and operates using 'short circuit' logic (the first false condition breaks fusion out of reading the conditions). Generally you want to put conditions most likely to be false higher up in the chain. If you have an expensive condition (any type of collision/compare two general values/etc) that is also likely to be false, then you want to move it up in the chain, but not necessarily to the top (since less expensive conditions that are more likely to be false should be highest). Keep in mind that condition order can also affect object scope if you're using overlap conditions as well as value conditions (check for overlap of an object before comparing to its value so that the correct object is scoped, for example). IMO, the best order for conditions is: least likely to be true, not very expensive > least likely to be true, expensive > most likely to be true, not very expensive > most likely to be true, expensive

-Uncheck 'use Fine Detection' on actives if you don't need it. This is especially crucial for large actives and anything that you will be scaling with events.

-Always use arrays over ini and list objects unless you absolutely need them, as arrays are much, much faster

I was told by Anders a while back that, when possible, order flag conditions first because it is the first condition checked. And that aligns with the logic casleziro mentioned. He is pretty much spot on in his approach.