I believe it works much like a self-fulfilling prophecy. Language designers think that it is more readable, so they do it. Language users use it and became habituated to it. So it becomes more readable because some people believe that it is more readable.
What is unreadable with:
a.extend(b)
c = a.clone().extend(b);
Programmer have all the control of memory management, and at the same time she is free to do any operations on lists, to chain operations, to do everything. And all her intent is here, it is written, it is obvious. While a += b... It leads to a need to write articles describing the difference between + and += and how could I possibly know did programmer who wrote the code read all such articles? Did he wrote he intended to, or what is nicey looking, but not great semantically? Did I read all these articles or I missed something?Even if it is more readable, does it justify all the obscurity?
Which, it turns out, you sometimes don't. It's especially bad when you think you know what it means, but you're mistaken.
I was kind of joking, of course, but only kind of. I'm a happy user of operator overloading.
You ask about a.add(b) but notice that's also using two operators.
First it needs a . operator for member access. Languages rarely allow you to overload this operator because doing so makes your head hurt, but there's no reason in theory it couldn't exist.
[In Python we can use __getattribute__ to meddle with this, but to avoid infinite recursion we can't use __getattribute__ to meddle with the operator overloading, such as __getattribute__ itself... ]
Second you need a () operator to call the member. This you can sometimes overload, for example in C++. So what this does might be defined by that operator overload.
The only way to avoid this being too confusing to use is to obey conventions, and even once you do that many of the operator overloads will be rarely needed and one wonders whether to just abolish overloading them.
Worse, unlike a function call, operators sometimes come with other semantic expectations that may be impossible to enforce.
For example the operators && and || are short-cutting logic booleans, in almost any programming language with such an operator, in_cache(foo) || slow_check(foo) only performs slow_check(foo) when in_cache(foo) was false. But an overload can't ensure this! Instead both will be evaluated and the results provided to the operator overload function, too late to optimise.
Overloading should be used very sparingly. If any significant fraction of your users find your overload confusing, it was a bad idea. Better than ten people wonder why they must write a.add(b) than that one person writes a + b and then is completely astonished by what you decided that does.