The restriction is a good thing because there are very few humans who can reason about acquire/release semantics in situations other than locks.
I would also note that aside from formal methods, LLMs are absolutely not trustworthy but the top frontier models can reason to some degree about weak memory orderings, and can at least find concurrency bugs which can be later confirmed by human expert review (preferably after eliminating false positives via adversarial LLM review of the findings).
> Atomic variables can be used simply and safely, as long as you are using the sequentially consistent memory model (memory_order_seq_cst), which is the default.
That’s from https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
A lot of companies’ in-house guidelines then say you are allowed to use acquire/release if you are implementing a lock, relaxed if are implementing a counter.
This IMO probably reflects most companies’ distrust in their own developers to develop lock free data structures.
Arguably, seq_cst is helpful for informal reasoning, because it's not hard to imagine all permutations and interleavings. But in my opinion, nobody should be doing lock-free programming based on informal reasoning. Algorithms should be considered incorrect unless they've been rigorously validated, ideally with formal methods or at least model checking.
Very few lock-free algorithms require sequential consistency. There are exceptions, such as Chase-Lev queues, but they are rare.
The added confidence that seq_cst gives you if the algorithm hasn't been properly validated is IMHO worthless.