For fucks sakes, nobody invents words like "monad" to sound elitist.
If so, well done!
If not, then I humbly ask why is a term such as monad qualified as elitist, yet terms such as Abstract Syntax Tree[0], Big O notation[1], and Turing complete[2] are not?
All four of these have in common precise definitions.
All four of these have in common applicability when considering the domain each address.
All four of these have in common their existence in programming even when not directly considered by those writing software.
0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree
The preciseness of the definition has nothing to do with the perceived elitism. Plenty of precisely mathematically defined concepts, as you've illustrated, can be (and are) explained to people without ever needing a single glyph or axiom in the explanation, let alone a recursive terminology briefer.
Take the following two definitions:
1) A screw is a mechanical device that converts rotational motion to linear motion, and torque to a linear force.
2) A screw is something you use to attach stuff to walls. You use a screwdriver to mash it in there.
One is abstract yet precise. The other is non-abstract and imprecise...so imprecise that it might as well be wrong. Regardless of its cringe induction potential to the Haskell-lovers brain, only one of these definitions will hold the attention of a 4 year old and explains why they're useful and how to use them.
The simple fact of the matter is that people in general are bad at math, and even most people who think they are "good at math" have no fucking clue what category theory is...good luck holding their attention while you brief them on it. Nobody learns abstract before non-abstract, it's just not how brains work. If you give them a reason to hold on to the concept, and explain it with words they likely understand, you might get far enough to one day explain the abstract version.
Fair enough. So here is a book which does precisely that:
"Functional Programming in Scala" (ISBN-13: 978-1617290657)
The authors incrementally present FP concepts, including monads, in a very approachable style. I can say first hand that this book does not require a heavy mathematical background (off hand, I don't think there are any formal proofs in it).
I agree that Monads deserve our time and attention. Unfortunately, search for monads and you'll get thousands of articles explaining what they are in incomprehensible terminology, along with language-specific type annotations, and devoid of any practical reasons to use them over their non-monadic control flow cousins in imperative languages.
They never seem to explain why you would ever need them, how they help in certain situations. Even worse, they don't tell you when they might actually be hazardous or code smell. They rarely even gloss over the challenges (like needing monad transformers if you want any sort of monadic composition), leaving you to figure that out for yourself when you start bashing your head against the walls.
For all their hard-to-google non-standard terminology, the Scala and F# communities have done a far better job than Haskell at explaining Monads in a way that actually makes people want to learn and use them. And once they have learned the concepts, the elitist sounding language doesn't sound quite so intimidating anymore.