The thing the article misses that I personally like about Haskell's drawing interface names from math is that it makes the edges sharper. There's more room for argument about whether something is "really Mappable" then whether something is "really a Functor", and more room to be uncertain about what guarantees I have in using the interface.
Something is Mappable in Haskell when it instantiates the class and satisfies the necessary and sufficient conditions it is obligated to by informal yet explicit contract of the class. That is to say that definitions are what guarantee validity, not connotational semantics.
This misses the social component, which I think is pretty important.
Why isn't Set a Functor? Because it doesn't obey the functor laws (because a == b doesn't imply f a == f b). Why are those the functor laws? Because that's all that Functor means.
Why isn't Set a Mappable? Because it doesn't obey the Mappable laws. Why are those the Mappable laws? Because they're the Functor laws? Why should that be the case? Maybe we should pick (or have picked) different laws for Mappable? Maybe we'll find better laws for Mappable, but we've given up that rarefied connotative linguistic real estate. There's extra room for drama and bike-shedding that isn't present when we're using already established names that precisely describe the interface even if they happen to be unfamiliar.