I can give a couple of "rather academic" issues that the status quo causes:
An example of where this has bit us in the hindquarters in the past is that the old Error class based instance for Monad (Either a) from the mtl incurred a constraint on the entire Monad instance in order to support 'fail'.
This ruled out many applications for the Either monad, e.g. apo/gapo are based on the real (Either e) monad, just as para/zygo are based on the "real" ((,) e) comonad. This rather complicated the use of recursion schemes and in fact was what drove me to write what turned into the "either" package in the first place.
Now we don't try to support 'fail' at all for that Monad. Under this proposal though, one _could_ add a MonadFail instance that incurred a rather ad hoc constraint on the left hand side of the sum without encumbering the Monad itself.
In general you have no way of knowing that you stick to the product-like structure of the Monad in the current ecosystem, because 'fail' is always there, you can get to values in the Monad you couldn't reach with just return and (>>=).
Ideally you'd have (forall m. Monad m => m a) being isomorphic to a, this can be useful for ensuring we can plumb user-defined effects through code:
but in Haskell as it exists today you always have to worry about it invoking a call to fail, and having a special form of _distinguishable_ bottom available from that computation so it is really more like `Either String a`.
Can you just say "don't do that?"
Sure, but it is the moral equivalent of programming with nulls all over your code.
-Edward