Agreed. Just a couple days ago I was having a discussion with someone about how Haskell's type system is able to quarantine effects (he's a long time C++ and Python user who wanted some help seeing how a type system could possibly do that). I managed to explain it without ever using the "M word".
Instead, I explained that "functions" in Haskell are deterministic and that "procedures" have a different type from functions. From there it was pretty easy to add that there are also types that represent more-restricted kinds of procedures that only have access to a limited set of effects. If he ever decides to take the plunge and actually learn some Haskell, I'll connect the idea up to the Monad class as "the minimal interface common to all procedure types", with emphasis on the idea that it's just the minimal API necessary to make something like "do" notation work.
That is really all a user needs to know about monads to get started with using them. Of course they need more if they'd like to implement their own, but by the time they're thinking along those lines most people will have already learned enough about them from osmosis since, as other people have remarked, it's not a hard concept - it just has a lot of prerequisites. Even then, though, most of what most users want is well enough served by a similarly shallow understanding of monad transformers (they add features to procedure types, etc.)