Referential transparency is something you can reason about. While technically monads are "reasonable" you are not going to reduce them by substitution. Yes, you can if you have a good imagination, but how does it help? While combining effects is thread safe etc., executing resulting function not necessary is. So we just kicked the can down the road adding another layer on top of existing compiler.

Monads is a nice way to hide state I have to admit, but not because of referential transparency and "reasoning".

If we're talking about Haskell monads, they are referentially transparent, and they are very very easy to substitute. For a specific example, see: https://en.wikibooks.org/wiki/Haskell/Understanding_monads/M...

Each Haskell monad might have a different implementation of the >>= (bind) operator, which is referentially transparent and which you can easily substitute. The IO monad would be an exception: I believe that one is not referentially transparent and thus cannot be substituted, because it's not implemented in Haskell. You can however imagine that it is a sort of state monad for the external world, but that's a fiction in practice.

(Note: Haskell monads are not "real monads" from category theory, and nor are monads in any other programming language AFAIK... So it's helpful to be very specific about what we're talking about when we use the word "monad" without context. You can implement a monad-like thing using classes in Python or many other languages, but those aren't referentially transparent and aren't typically the monads people are talking about in the context of pure functional programming.)

I'd argue that the difference between a monad and any old type with operations of bind and pure's types is precisely reasonableness -- I can expect Control.Monad.forever to work because the monad laws allow me to reason about monads as an abstraction rather than caring about the precise way the Writer monad might be implemented.