What helped me grok the mathematical rigor is: If you have a series of monad operations that exist purely in monad world -- in Haskell, if your expression is parametric over the type of the monad -- you shouldn't have to worry about how you do it.

This is what monads being categorically commutative ("a monoid in the category of endofunctors") buys you. You want to turn monad X into monad Y? Sure, just join, flatten, return, bind in whatever way makes the type checker happy. Anything that only uses what's in the Monad typeclass must necessarily be a monad morphism, so if you're generic over your monads, you get that for free. And of course `fmap` and `bind` are required to be parameterized monad morphisms, so there's a lot you can get for free.

I think you mean associative. Neither monads nor monoids are commutative.

...Sorry, that was unclear. Monad-as-monoids being associative corresponds to certain categorical diagrams being commutative.

It's the concept of categorical commutativity that's what's useful. A collection of types and functions is "commutative" if every way to get from type A to type B yields the same result. It happens a lot in Haskell where most or all of the operations you're interested in commute with each other, which is how Haskell gets its reputation of "if it compiles it works". In particular, if you `fmap` or `bind` two commutative functions, the result becomes commutative, too.

Very misleading since monoids include a binary operator and the algebraic definition of commutative would imply that A * B = B * A. Clearly this is false if A and B are strings and * is concatenation (which forms a monoid with the empty string as identity).

Yep, you need category theory to express something as trivial as the definition of a monad.

That’s what category theory does well: broad collections of trivialities in a unified definition.