It's not completely random, but the order of the modules does affect the amount of SRAM used, because with a less ideal ordering of the modules, the patcher may need to add temporary variables to hold the values of the various signals.
Basically, the patcher puts the runtime code for all the objects after each other, which is decided by their graphical position in the patch, and then completes the connections between the inlets and outlets. The code is then run in a loop, one sample at a time (this is a simplification, because the Axoloti actually processes 16 samples (k-rate vs. s-rate) at a time, but for the purposes of this discussion this is not important).
Now, say there are two modules in a patch, one sending to another, like an oscillator to an output module. If the oscillator ends up being placed after the output module in a patch, the patcher has to create a temporary variable to hold the output from the oscillator for the next loop when the output module can pick it up on its inlet. This happens automatically so the user doesn't have to worry about module ordering - until there is a shortage of SRAM, when it becomes a very concrete problem.
Hm, here's a thought, it would be nice if the patcher could output the number of such temporary variables it needs to create when the module order is less than ideal, so that it would be easy to check the efficiency of ones patch. In a real patch, it can be hard to eliminate out-of-order modules, but one could at least try to minimize them.