He’s implying that a processor-specific detail should not show up to a person using a framework that “abstracts” details like that away from the programmer.
If you are using low-lock techniques like volatile fields, explicit memory barriers, and the like, then you are entirely in the world of processor-specific details. You need to understand at a deep level precisely what the processor is and is not allowed to do as far as reordering, consistency, and so on, in order to write correct, portable, robust programs that use low-lock techniques.
The point of this feature is to say “I am abandoning the convenient abstractions guaranteed by single-threaded programming and embracing the performance gains possible by having a deep implementation-specific knowledge of my processor.” You should expect less abstractions at your disposal when you start using low-lock techniques, not more abstractions.
You’re going “down to the metal” for a reason, presumably; the price you pay is having to deal with the quirks of said metal.