Thanks for the bump, those are good questions and it’s a shame they were unanswered.
In normal events, each instruction (condition or action) that accepts an object as a parameter will be repeatedly executed for each currently picked instance. In a for each event, all instructions (even ones that do not use objects) are called for each instance of an object.
That’s kind of hard to tell, the best way is to look at used objects, then think about the instruction and try to imagine how it could be implemented.
For example, the “Mouse released” event must be rather simple, it does not use any object so it is not being repeatedly executed, and internally it must simply perform a check against a boolean value (the button can either be released or not), one of the (if not the) most basic operations a computer can make. Therefore, this condition is very very fast to execute.
On the other hand, a collision check uses two objects, so the times the condition is run is multiplied once by the number of instances of the first object, and again by the number of instances of the second object. Additionally, each check needs to be made for every polygon of the collision mask of the objects, so it gets multiplied again if you use masks with multiple polygons. And finally, it is hard to think of a trivial implementation, such a condition will have to use some complex maths. All those factors allow guessing that the condition must be very bad for performance.
In addition to that, it’s always good to run some benchmarking by putting some test events inside of groups and looking in the profiler which are the shortest to execute.
Since this question was asked before GDevelop 5, I will first answer in regards to GDevelop 4’s native platform:
Most of the time, yes. If two strings are not of the same length, the comparison will check after comparing length and the performance will therefore equal comparing two numbers. If they are all of the same length, then it will have to check character by character for differences, so it will add one check for each same character. If the strings are equal, it will still take about the number of characters of the string times more time than number comparisons, since the check has to run for each character before equality is certain.
For example, "state_a" and "state_b" will usually take about 7 times more time to run than a number comparison, since they have the same length (amount of characters, 1st operation) and then will check the first 6 characters ("state_"), which equals to one number comparison each, before finding the difference between the two strings.
If you have strings "walk" and "running", it will have the same performance as checking two numbers, as their length differ.
If you compare “hello, my friend :)” with another occurrence of that string, it will take 20 times as much as a number comparison, as it has to check length, then every 19 characters of the string.
In GDevelop 5 and the JavaScript platform generally, though, there is an additional optimization (that is not guaranteed but practically present in pretty much all JavaScript compilers): interning. This allows to make most checks as long as a number comparison, so you should be fine with strings there most of the time.
External events are basically copy-pasted in place of link events at compilation time, so they cannot be “unlinked”, but you can disable all of its events by putting the link event under an event that checks for a variable that you can modify to toggle the execution of the external events on and off.
Not really. If your events use conditions on the unexisting objects, the condition will not even run and directly return as not met, not running the rest. If you are using some events without object conditions that are not composed exclusively of object actions (object instruction == an instruction that takes an object as a parameter), then the free actions (actions that do not take an object as a parameter) may still run. In that case or if you want to be extra sure, you can add a parent event to all of your events for an object comparing the number of instances of the scene to make sure there is at least 1 before executing its events.
Exactly 
. Always put free conditions, performant conditions, and conditions that are likely to be false first. An unmet condition will always skip over the next conditions, actions, and subevents.
Also use subevents to run conditions only once instead of multiple times, like this:
I sadly cannot really answer that one as I lack knowledge there, though I assume that particles are more performant than sprites if you do the same operations on a sprite than on the particle, like, particles have pretty much all their properties changed every frame (opacity, position, existence, color, …), so sprites can be more performant if you do not do all of this. But then again, I have no real knowledge there, so take this with a grain of salt.