It's how Haskell programmers do things in order while maintaining all the other guarantees of the language (related to state, laziness, etc)

You basically need monads with all the other guarantees of the language. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html is a good article on this opinion on them.

Monads, while not needed in most other languages, are neat and clean in a way many other control structures in those languages aren't. You are going to understand monads if you do anything big in Haskell. You just can't really get that far. But the real joy is using them in other programming languages to get side effect free implementations of a lot of complex initializations and transformations. See Ruby, JavaScript, Objective C (This implementation of maybe is particularly instructive as to what it's replacing), and C#

Haskell, in general, is willing to use what I'd call "Poorly defined in English concepts" if they have strong functional (in the typical english sense of the word functional) or structural definitions, if you have a strong symbolic description of how something works.

I'd almost say Haskell is willing to use "named but unexplained" concepts a lot.

My English definition would be: Monads are a set of side effect isolating ways to chain operations. They are probably the simplest way to do many things in Haskell, but a pretty good way to do things in imperative and other functional languages much of the time to isolate failure concerns and improve the likelihood of correct results

You've probably written much of a monad if not its entirety if you ever tried to make some sort of logging, item creation system, etc very chainable in another language.