This comment would be stronger with some kind of examples or other reasoning about the kind of problems this avoids.
In particular, the dichotomy you created which paints the two options as “advanced mathematics” and “intuition” seems to need some proof that there is no third option. Since the original poster mentioned OOP, that would be a good place to start with some example of a problem which is hard to avoid following good OOP practice.
It’s not a dichotomy, it’s a fact. Lucretius had the idea that the world was comprised of atomos (by way of Epicurus). Without mathematics and science he didn’t have a theory. His intuitions got him far and maybe it set the stage for Dalton but Lucretius’, The Nature of Things wouldn’t be the foundation of discoveries that leads to new understanding.
In programming you end up with JavaScript Promises instead of proper monads because of similar appeals to intuition. A monad obeys certain laws upon which further abstractions can be built. Promises do not obey those laws and so one cannot benefit from them. A programmer has to learn what a Promise is and how it behaves. You learn what a monad is once and anything that is a monad behaves the same way.
The reason why it’s important to use the proper names is so that people can find the original definitions and theorems. You don’t have to be a category theorist to use a monad. You can have a basic understanding, as I do, and get by fine. However when you want to understand the theorems to build your own abstractions it’s great being able to go straight to the source.
Simon Peyton-Jones has a good explanation for why Haskell took this route in his talk, Escaping the Ivory Tower.
Good OOP practise does involve writing things down. Just look at design patterns books or c2 wiki.
My contention is not that writing things down or naming abstractions is bad. On the contrary i think that is a good thing.
I don't even think monads are a bad abstraction. Monads are a fine abstraction. Its the baggage people carry with it that is the problem.
My main contention is that people are cargo culting the way monads are explained in category theory and applying that to computer programming. This sort of works, but generally not that well because its copied from a field with very different goals.
Math wants to prove things in the most general way possible. This lets them explain & discover the deepest possible patterns. They trade complexity to achieve this goal.
Computer programming aims to solve problems efficiently in a way that is efficient and easy to modify. Complexity is the enemy of this goal.
Even in math, you might prove that some object is a monad or whatever, but you will still generally work from its normal definition and not from the definition of a monad.
In particular, the dichotomy you created which paints the two options as “advanced mathematics” and “intuition” seems to need some proof that there is no third option. Since the original poster mentioned OOP, that would be a good place to start with some example of a problem which is hard to avoid following good OOP practice.