What the article suggests seems to be more along the lines of a clippy lint warning agaunst use of these orderings, which wouldn't be a breaking change.
I am vaguely uncomfortable with this idea for reasons I am struggling to put into words, but that is a more viable path, yeah.
Soft-deprecating something in the standard library with a clippy lint feels a bit off for me too; I think that if something in the standard library is going to be discouraged, it should be done in the standard library itself (e.g. through documentation and/or using the deprecation warning). Clippy is absolutely phenomenal, but I tend not to think of it as something that's intended to be required by all users. Using it as a way to keep track of discouraged std types feels like it could easily lead to fragmentation where users stop looking to the standard library as the source of truth for its own contents.
And after some period of that it could be made unsafe in a future edition. So it’s not a totally crazy idea, but the payoff would have to be quite something.
For most of the cases I use relaxed or have seen it being used, it seems to be a loss. It's often to e.g. increase some shared metric counters from multiple threads - where there's no real ordering concerns, and the only thing that matters is that it counts right and not when exactly he value gets visible. The cheapest possible atomic operation which can fulfill that use-case (relaxed) is fine there. Having to use `unsafe` for that doesn't seem too appealing.
You cannot currently change the API of the standard library on a per-edition basis.