Yes, I attempted to address why this was left unmolested in my last couple of paragraphs.
For comparison, we have not generalized map to have the same signature as fmap because we do not have to. fmap already exists,
having the less general signature directly indicates why it isn't possible for you to use
instance Functor Foo where
map = ...
and a large portion of the community would like it to remain ungeneralized (often for teaching purposes).
Given that we already have a polymorphic combinator in Prelude there is no need to make their teaching tool more awkward to teach with. As it is, teachers already have to get into typeclasses before they can talk about foldr, and this already causes a fair bit of consternation.
If we had everything to over again and no installed base? I'd probably say map should have been the member of Functor, like it is in most other languages that have anything even remotely resembling type classes at this point. The pain of transition doesn't warrant it, however.
Similarly, (<>) is winding up in Prelude as part of the Semigroup/Monoid proposal. (++) was explicitly un-generalized in Haskell 98 for teaching and error purposes, and we have (<>) present and moving into Prelude, so there isn't a real reason to go and generalize the second name and there is at least a weak justification for leaving the status quo in place.
Having two operators for the same thing means another side-condition to learn, another quirk to learn, etc. You still need to memorize which one you are allowed to define in Semigroup. The folks who write that same fiddly kind of pretty printer code do derive some benefit from keeping those operators separate.
Finally, The status quo at least lets us dream the dream that we could remove (++) entirely from the language some day. (Even if we're unlikely to act on this impulse due to the fixity concerns raised above.)
-Edward