I think the point is even better than a joke: there is a danger in allowing things like, e.g., operator overloading (or redefining methods in the standard library), because programmers have different feelings about what the code "obviously" means.
If in your language, + means string concatenation by convention, then + darn well means string concatenation. If in your language + means "contextually appropriate depending on what arguments you pass to it", then
"abc" + "def" => "egi"
doesn't strike me as obviously wrong.
More broadly, consider a language in which we teach initiates that "Plus adds things in the way you'd expect!"
map = {}
map2 = map + {"key" => "contents"}
What are the contents of map and map2 now? Uh oh. More worrisome:
This whole line of reasoning reminds me of the Java3D API. Java, of course, takes the approach that only the designers of the langauge were smart enough to know when to abuse operator overloading (e.g. with strings), so for the Java3D math API, they couldn't have nice syntax for vector arithmetic. Instead of having nice operators for addition (+) and accumulation (+=), they just have english, and they want it to be terse, so the accumulation method is .add, and there is no addition method for vectors. It's not terribly confusing, but seeing vec1.add(vec2) rather than vec1 += vec2 is ugly and you still have to read the documentation to know what the .add method does.
Avoiding operator overload doesn't avoid poorly named methods, nor does it avoid the need for documentation. All that it does is force programmers to do ugly things when dealing with math, and there is a lot of math-based programming out there.
1) I did say 'savvy'. Sort of because I don't get to use that word enough, but also because it is possible to abuse operator overloading. String concatenation with the addition operator isn't going to suprise anyone, even if you come from another language (well, it might, but the choice of the + operator isn't an unintuitive one). Furthermore, nobody's jumping at things with well-defined operators, like vectors/matrices, etc. I've written very little outside of a maths library that used operator overloading, but it's a godsend for the cases where it's appropriate... probably a truism.
Secondly, they're just functions. You can look them up (y'know, assuming you can), you can optimise them, and you can document them. A programmer encountering an operator doesn't have to rely on their interpretation alone, and indeed shouldn't. They should know what that operator does. Now of course, if the operator has absolutely no contextual reason for existing, or is suprising divergent from its apparent purpose... well, see point 1.
As for your example, how do you do a greater-than-or-equal comparison on strings? :D
I always thought a huge benefit of lisp using S expressions is the lack of infix operators saves a lot of time and energy arguing whether/when they should be overloaded.