Having taken the rite of passage that is writing my own monad tutorial, I would agree, the concept is both easy and intuitive. Getting it in to your head, however, takes considerably more work than in any other language I've used.
Ask yourself: why does everyone write a Monad tutorial after they understand Monads? It's because they seem obvious in _retrospect_. The only tutorial I've seen that's anything like approaching a "works for everyone" tutorial is "You could have invented Monads".
As to your specific explanation, I think it falls down with IO ().
Yes, the mathematical background for the concept is very abstract, like everything in category theory. But in a way, talking about that is like going into "Principia Mathematica" to explain how sets work.
You can also just say that monad is a name for the general kind of thing that you can use with the do syntax. That is, types that support binding variables and returning values.
That the abstract mathematical theory of binding variables and returning values is a bit abstruse is not such a big deal. People can use IO without really grokking the theory of monads.
Yeah, to people used to imperative languages, it's surprising that you can't just call an IO thing in the middle of your function.
But that doesn't mean Haskell makes IO difficult. And it doesn't mean Haskell is a bad choice for IO-heavy applications.
I worked at a web startup that used Haskell for its backend. It worked extremely well, was quite short and clear, and rarely had problems.
I was trying to avoid replies like this with my disclaimer at the beginning of my comment. I've deleted it.
I was trying to avoid the low-effort dismissal you put forth by saying it was a very silly explanation.
What do you think you've accomplished?