I can't speak for the poster you're replying to, but in my personal opinion, monads exist at a higher level of abstraction than most people, even experienced imperative programmers, are accustomed to. The formal definition of a monad is quite simple, but it can be challenging for a newbie to extrapolate from the literal code that defines a monad to see how and why that pattern is widely applicable to so many seemingly distinct, unrelated problem domains. Eventually, through usage, you develop an intuition for it and it seems plainly obvious. But despite the proliferation of "monad tutorials", there are no magic words that bring understanding. Newcomers want to have it explained to them without having to get their hands dirty by writing code, but the only way to really acquire an intuition for something this abstract is through experience.

The other problem I see is that monads are really hyped (over-hyped, in my opinion) as a huge stumbling block for new Haskellers, and this turns out to be something of a self-fulfilling prophecy. By the time you reach the monads chapter of whatever book you're learning from, you've already read 5000 blog posts and HN comments about how difficult and confusing monads are going to be, so you go in expecting to be confused. And this just contributes to the confusion. I think that it's much easier to learn this sort of concept if you can go into it without any preconceived notions about what to expect. But since monads are something that all Haskell users like to talk about, publicly, it's next to impossible to introduce a newbie to the concept without them having already heard about the difficulties they're about to face.