I'm much more in favor of pushing folks that want warnings of this sort of behavior towards custom HLint rules for banning behavior (which can be done today, but probably comes across as too weak) or towards seeking a general mechanism to name a set of methods you'd like to explicitly warn about during compilation time (so that mechanism could be more uniformly applied across third-party code bases, but which requires a design and GHC engineering effort) over applying a WARNING pragma as a blunt instrument to this particular problem.
(As an aside, let x = x in x can throw a NonTermination exception without ever invoking any explicit throwing mechanism, depending on how nice your runtime system wants to be, so being "exception-free" here is confusing phrasing to me.)
WARNING as it stands is far too strong. There are plenty of cases where they are the only thing you can do, due to limitations of the totality checker or invariants that Haskell can't express holding behind your back.
A rule of thumbs I've tried to keep in mind towards existing warnings and deprecation efforts is that a WARNING or DEPRECATED pragma that leaves you with no alternative but to listen to the compiler scream even when you are doing your utmost to avoid it short of disabling all warnings is a badly designed warning or deprecation.
-Edward