Monads are a very effective technique for expressing custom requirements in your type system, e.g. "this function must be called only in a database transaction", "this function writes an audit log entry", "this function requires this level of authorization". The kind of thing you might think you would have to do via AOP/decorators/monkeypatching, you can usually do in plain old code (with all the attendant advantages) via a monad.
If your type system can't express them then you lose most of the advantages and they're pretty pointless.
> why `m a -> (a -> m b) -> m b` but not something else?
it's basically continuation-passing-style (`a -> m b` is the "continuation"), you might as well ask "why can you represent so many control-flow things using CPS?". idk why, but you can!
from another angle, you could compare Monad with the less powerful Applicative. a formulation[0] that's easier to parse than the usual one[1] is:
class Functor f => Applicative f where
unit :: f ()
pair :: f a -> f b -> f (a, b)
if you're familiar with JS Promises, a rough analogy would be
Some people describe monads as "programmable semicolons" - they're pretty much the general concept of sequencing, "do this then do that", or indeed of imperative code. I don't think they're necessarily the ideal abstraction - something like ArrowChoice is "better" in a lot of cases - but in practice they seem to come up a hell of a lot, you can represent almost anything as a monad.
Why monads and not something else? Because monads appear to be a/the mathematical structure underlying the denotation of programs with effects.
Why that type signature? You only have two options: that, or m (m a) -> m a. The former is more popular for ergonomic reasons mostly. It doesn’t really matter.
If your type system can't express them then you lose most of the advantages and they're pretty pointless.