Well, that's the main problem: if you're using monads, you'd use a language that already supports them natively. That assumes you're already familiar with the language and surely know what monad is and how to use it. See, these concepts from FP are bit too abstract for imperative languages that are far more common. So it's a chicken and egg problem and unfortunately explaining monads in a functional language doesn't help to break this cycle.
I've always seen Haskell as a purely academic language. Not much known software is written in it that I can name right off the bat. Only xmonad perhaps. I don't think it's a coincidence that it's not widely used in solving practical problems. Can't tell anything about Elm, didn't see it. So, why would I want to write my own monad? What exact problem would I solve with it that I can't without? Just a real life example. Everywhere monads are explained on Maybe and yes, I know that Optional is more or less that. But other than that? Java also has streams since 8 and they feel monadic, like you can apply a function on Stream and get Stream in response. That's cool and I don't see why you need a functional language to do that.
Also, this article, despite explaining everything in Haskell again, was pretty informative. It has a lot of pictures without confusing analogies, totally recommend it. Unfortunately, it's yet again about Maybe.
Sounds like you've already got a feel for what's monadic and not :-)
Mind though that streams can only be monadic is they are finite: an infinite stream of infinite streams is a higher-order infinity (∞2) which mathematically cannot be mapped to infinity, so no chance for a flatten function. Neither can you 'follow up' on infinity (andThen or bind), ergo not a monad.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.