No, I am not talking about preprocessor macros. I'm talking about a live, vibrant, run time constant that would help the executable code to make intelligent choices based on its environment. I have supplied at least two examples where it might be helpful: i) how to interpret the command line tokens in the Command() array, and ii) where to load resources from.
If the script runs JIT compiled, Command(1) will be gxo2.exe, Command(2) will be scriptname.o2bas, and Command(3) will be the script's parameter, say, -h. If it runs compiled, Command(1) will be scriptname.exe, Command(2) will be -h, and there won't be any Command(3) at all. Hence, i) we can't rely on -h always being in the Command(3) position, and ii) we are running the risk of a crash if we don't know CommandCount(), or the UBound of our Command() array. (see my griefs in a similar topic named Why Don't We?)
If the script runs JIT compiled, it is natural to expect its media resources to be grouped in a temporary folder alonside the script. But it is unnatural to expect this folder to be deployed together with the executable compiled from that script. That's OK for a Mac app, but it is not becoming to a Windows application.
You can invent a dozen other similar situations where STANDALONE is coming in very handy.
As for other run time constants, say, to differentiate JIT from dynamic JIT, they may be introduced if you find some common enough reasons like those above to justify their existance.