The point of the exercise is to show that the C++ idiom doesn't make sense in Rust. It's certainly not trying to imply that Rust is being unreasonable for rejecting a direct port of a C++ idiom.
I do think the ambiguity mentioned in the article -- that &mut really means &uniq -- is the core of the confusion. If &mut were called &uniq, I would have had no reason to consider &uniq a direct port of a non-const pointer. That's probably the most important thing I learned when researching and writing this article: that &mut really means "exclusive", not "mutable."
But the C++ example does indeed make sense in Rust, if implemented appropriately. Sometimes you need an atomic, and the type that contains one should require no further synchronization. In both languages it's an equally useful tool.
I agree that more could be done to clarify that &mut should be read "exclusive". You have an opportunity to help in this article. Don't just leave the compiler error and move on, which gives the impression that modifying an atomic is just impossible in Rust... Take the chance to explain why the naive port is not idiomatic.
I do think the ambiguity mentioned in the article -- that &mut really means &uniq -- is the core of the confusion. If &mut were called &uniq, I would have had no reason to consider &uniq a direct port of a non-const pointer. That's probably the most important thing I learned when researching and writing this article: that &mut really means "exclusive", not "mutable."