That would go under "optimizations". My example was a worst case, brute force scenario, using more calculations and being altogether more pessimistic about the ramifications of those calculations than needed to be. And it still only came out to a fraction of a second to check most of the map in that style. It's not something you'd want to happen every time you mined a tile or moved anything around, but it's also not a definite FPS killer.
Optimizations like keeping the last mechanical stress number and comparing it to the new would increase the memory footprint of the system, but would seriously speed up its execution. That's a good point too, and something that should be really considered.
If storing one number per tile and comparing it to the last valid result, as that would, could potentially save a lot of calculation, as that would, then it should be considered.
However, it doesn't really change the amount of calculations needed to be performed on a Cascade-style system. If the weight support calculations "flow outward" from a spot, any time a tile's support environment is changed those changes in force will need to flow outward. If the system is coupled with the reductions in transferered weight that I outlined, at a certain point that "flow" will stop naturally. This basically models the same situation you're talking about, but would be a bit more abstracted and a touch less computationally intensive.