David: I think the resistance you're seeing is coming from the fact that- at least in my experience- liftMN is not considered good, idiomatic Haskell code, since the idea is expressed *better* by <$> and <*>. There's been a downside until now that <$> and <*> introduced a different constraint (Applicative instead of Monad) but, as you already mention, AMP will solve that.
So- at least for me- adding in liftA2... would be a step *backwards*, since it encourages people to avoid the idiomatic solution for the non-idiomatic solution. In fact, I wouldn't be surprised if you'd get less resistance to the idea of deprecating liftM2... (though please *don't* propose that, there's no need to break backwards compatibility).
But let me ask something else: why not just change the type signature of liftM2... to have an Applicative constraint instead of a Monad constraint? Besides the funny naming, that would seem to address your concern, without increasing the number of non-idiomatic combinators.