I think I you are probably right in principle; with the current solution, any nets who do not need to be saved across dsp() calls could be held in registers and thus never written to memory. I would think though that given the complexity of the dsp() function, most if not all net variables would be held on the stack anyway (which of course also is in memory). I would think it unlikely that the compiler could optimize them away completely, after all they do carry data. Perhaps the inlining of the individual dsp() functions can result in enough optimization to actually remove variables though.
And I guess due to optimization, for those nets that have Latch variables, the corresponding stack variable can be optimized away, thus avoiding the copying of auto to static variables that occurs in the block at the end of the dsp() function.
I agree it's often hard to predict how effective a compiler can be at optimization. In this case I think it might be worth while experimenting with both pradigms, and see when one actually results in lower dsp usage. But I agree with your reasons now that I think about it, and I can't say I'm convinced having them all static would be an improvement.
(One improvement though would be that objects could consider the outlet variables as being static, thus avoiding the need to have a local variable to mimic them. This would only be an improvement though for objects which don't update their outlets during each krate period.)
It's not really my main focus now though, but still .. which files in the Java code handle the generation of variables where this could be experimented with?