IMO the main reason this overcomplication tends to happen is that many of the Monads for Idiots guides are written by people just out of the period where they struggled with the concept, and they mistakenly think that the entire thought process that led them to get it is the best way to present the topic.

But teaching doesn't work that way, and more often than not presenting the 'long way' through a topic obscures the essential simplicity that actually helps people figure it out for themselves.

That burrito one is a good example; maybe interesting once you already know what's going on, but if you don't it's most likely just going to frighten you away.

That is the problem with the book Real World Haskell. The authors will spend most of the chapter showing you the wrong way to do it, then a paragraph at the end saying BTW this is the right way.

Kinda sorta the point of having any sort of pedagogical aid, like a book, is that it gives you at least a prod in the right direction. Learning something just to need to unlearn it a few pages later wastes everyone's time.

My take: Monads were created to allow pure functional languages like Haskell to have side effects, particularly input and output, without breaking the pure functional syntax. Monads have many other uses, but state and side effects was the original raison d'etre.

Haskell, for example, is a pure functional language that doesn't have an explicit syntax for side effects or state. But a language without any side effects can not do anything more useful than heat up the CPU: you have to have input and output, which means allowing for side effects. The Monad was the most elegant solution presented for that issue.

In code a monad looks like a function which has more outputs then inputs, and the compiler takes care of channeling the additional input and output between functions adjacent to the monad in way that doesn't break the functional syntax. This differential between function inputs and outputs allows for some interesting use cases and thus the many varieties of monads. Also the compiler makes sure the order lazy evaluations dependent on monads happen in the right order so that you're not trying to parse file contents before you've read the file (because in a pure functional language, like cells in a spreadsheet, everything is intended to be evaluated all at once).

This is because monads are terrifically useful for doing a number of things, but each thing is most easily explained in different, seemingly inconsistent mental models. Monads are an abstract, complicated category theory thing (it's a monoid on the category of endofunctors on the category of Haskell types, obviously!) and trying to explain the concept directly is too hard, so people talk about burritos and E-mails and other things that more reflect specific uses of monads than the general thing.