Is a conforming implementation permitted to transform this example to eliminate the load operation?

Generally yes, a compiler can statically decide that a certain order of atomic operations is the only one that can ever happen in the executable it builds, according to the current standard. (I don't think it's plausible that a mainstream real-world compiler would do that in a loop with a 1-second sleep. That's a very long time for normal computers, so it's unlikely that this possible execution would be the one that actually happens if compiled as written.)

For now the committee's guidelines are for compilers not to do optimizations like this until they figure out a way to let code opt-in to it, rather than having to use volatile atomic everywhere to opt out.

• https://wg21.link/n4455 : N4455 No Sane Compiler Would Optimize Atomics
• https://wg21.link/p0062 : WG21/P0062R1: When should compilers optimize atomics? - these papers have some examples of other loop transformations like sinking a store out of a loop and doing them all at the end which would be undesirable for progress-bar updates even if you used volatile atomic to make sure all the updates actually happened. So it's an unsolved problem, with the current standard allowing much more optimization than desirable for some cases. For now, real compilers are very conservative with atomic optimizations and never optimize them away.
• Can and does the compiler optimize out two atomic loads?
• Why don't compilers merge redundant std::atomic writes?