The general issue those macros want to prevent is that modern CPUs have a tendency to execute a lot of stuff out-of-order, *including* memory operations.  From the perspective of a single hardware core (or thread, really), that's fine since it  has a logically consistent view of the machine's state (it knows which operations have been reordered, which values have been committed to cache or not, etc.).  But what happens when another hardware core examines in-memory state at the same time? It might find values changing in a different order than the programmer had intended. If it's important that the visible order hasn't been changed, you have a bug.

Note that C "volatile" is not enough: it only prevents the *compiler* from re-ordering or eliding memory accesses, but not the CPU.  As such, "volatile" is only useful if you have a single word-sized piece of state that you need to inspect from several threads at once.  But the eval loop uses several of them, and therefore needs to prevent the CPU from writing or reading them in the wrong order (which may produce synchronization bugs such as deadlocks).

Also note that traditionally, x86 has a "strong" memory ordering model which prevents nasty kinds of reorderings to happen.  But other architectures such as ARM or SPARC can have much weaker memory models (IIRC, we had sporadic hangs on an ARM buildbot a long time ago, because of that, but I can't find a reference).

I admit I'm unable to vouch that the current code is correct.  Jeffrey Yasskin did the original change adding the Py_atomic types and using them in the GIL implementation.