That's not a monad, that's just typeclasses (also known as traits/interfaces/etc.).

If you're familiar with flat_map or and_then in Rust, you already get the basic idea of monads. Just imagine that instead of the ad-hoc implementations that Rust has to do (since it doesn't support higher-kinded data types), you could express it in a single trait. Then you can write code that generically works with any types that support flat_mapoperations (along with a couple of other requirements, like needing a From<T> impl, as well as abiding by some laws that are really only a concern for library authors).

If that sounds simple, it's because it is. It's mostly just that it just so happens that being able to write code in this fashion has some pretty significant implications. It essentially allows you to very strictly control the semantics of sequencing operations, while still giving you enough flexibility to enable many of the things you typically do in imperative programs. In a language like Haskell which is built on monads, it's a very powerful reasoning tool, much in the same way that purity in functions is a powerful reasoning tool. It allows us to do things like, say, represent async code blocks as first-class concepts requiring no special syntax (no async/await, etc.), because the monad interface allows us to dictate what it means to sequence async actions together (if you're curious to see what this looks like, here's a link to Haskell's Async type from the async library: https://hackage.haskell.org/package/async-2.2.4/docs/Control-Concurrent-Async.html#t:Async).