Monad, like any interface, is useful because we can abstract over it. Let's take an example from Java: both ArrayList and LinkedList implement List. This means

Monad, like any interface, is useful because we can abstract over it. Let's take an example from Java: both ArrayList and LinkedList implement List. This means I can write code that is agnostic to the implementation of List, and later I can drop in any implementation I want. Seen from the other direction: if I write something that resembles a list and I implement the List interface, all of the code that's compatible with List will also be compatible with my new implementation. Similarly, if I define a new data type, and realize that it can implement Monad (or more precisely: that it has a monad instance), then I'll be rewarded with a giant library of code that's already compatible with my new data type [1]. Monad is an especially interesting interface because (1) it turns out many things conform to it [2] and (2) it comes with a set of algebraic laws. There is some controversy over how strict we need to be about the algebraic laws, but in some sense the algebraic laws are part of why such a general interface can be meaningful at all. So yes, it's true that Monad allows us to sequence effects in a lazy pure language, and that's important, but I think a more down to earth reason to be interested is that it allows for more code reuse [3]. [1] Some of the function defined in the standard library: https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Monad.html#g:4 https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro... [2] See the 'instances' section here: https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Monad.html#t:Monad https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro... These are just the instances in the standard library. [3] It's also worth mentioning that Monad gets all the attention, but Haskell if flush with other mathematically inspired interfaces that are just as general.