The optimisation is (absent a bug in the compiler) valid, unless you've written UB in there somewhere. The _reason_ to try not to volatile something is that optimisation is quite a powerful one; if the compiler can prove something written to memory can't have changed since it was written, then it doesn't need to load it from memory if it's later used. Hits to memory can be quite slow, so this optimisation entirely removing the hit can make a big difference if the code is performance sensitive.
In the general case you're right, in this case where the optimization is related to the usage of uninitialized memory I don't think that you're correct.
Of course this means that the programmer must 'think like an optimizer' and rewrite
is-member(i):
return sparse[i] < n && dense[sparse[i]] == i
as
uint sparse = sparse[i]
return sparse < n && dense[sparse] == i
otherwise the compiler would generate two load instead of 1.