I think Haskell as a community favors more learning over having edges to abstractions. You could call Monoids "Addables" and it would make intuitive sense more

I think Haskell as a community favors more learning over having edges to abstractions. You could call Monoids "Addables" and it would make intuitive sense more quickly, but it would (a) face edge cases later (multiplication is a monoid, as is "take the leftmost argument") and (b) not link to a larger literature of abstract algebra. That turns a lot of people off, as you mention, since they want the names of things in their language to provide immediate (partial) intuition as to what's going on. The upshot is that reading Haskell expects more background literature in abstract algebra (or at least a willingness to read the docs for a while to learn a new vocabulary) but suffers fewer intuition breakdowns. I think that's a general theme of the style of Haskell programming—suffer few intuition breakdowns. It's reinforced by purity, equational reasoning, sophisticated types, top-level annotation style, some parts of laziness, etc. Altogether these pieces fit together to form something unique and interesting. So that tradeoff of immediate understandability is painful. The community is battling it by (increasingly) building more and more public documentation. Without that tradeoff Haskell wouldn't be as unique and specialized, though.