Since the day when the language Java was first advertised, more than 20 years ago, these discussions about whether operator overloading is good or bad have appeared, just because the authors of Java had an aversion for operator overloading.
All the arguments that I have ever seen against operator overloading are just various ways of formulating one single argument and this argument has nothing to do either with operators or with overloading.
The argument is that some programmers are stupid and they give names that are misleading, because those names mean something else than what most people would expect them to mean.
I agree that this is true, but it happens with any kinds of names, of variables, of functions, of macros and of course also with the operator symbols when it is allowed to define functions whose names are operator symbols.
I do not agree with this kind of arguments that some people are stupid and they might do something bad with a kind of tool so let's forbid to all people the right of carrying such a tool.
In my experience, the ability to understand complex programs depends a lot on whether you can see the entire relevant part of the code on the screen simultaneously. Few people have such a good memory that they are still able to understand the code if they are forced to flip constantly through multiple pages of text.
So there are places in a program where long descriptive names can make the program easier to read and understand, but there are also programs with complicated formulas, where a compact notation makes the code much easier to read and understand.
Many years ago, about at the same time when Java was launched, I worked at a program that computed the radiated electromagnetic field for some systems. The model required a large number of custom types corresponding to various physical quantities, and most of them had values that were vectors of complex numbers.
The code contained a large number of very complicated formulas, corresponding to multidimensional integrals of various functions.
The initial version had been written in C, and the text of the program was huge and extremely difficult to read and understand.
Rewriting it in C++ with overloaded operators resulted in a dramatic reduction in size and it became possible to understand what happens in the code by just reading it.
At the same time, the Java propaganda against overloaded operators began, but obviously, after my experience, I dismissed it as misguided.
I agree that C++ is not an example of how it is best to handle operator overloading, because C++ allows the overloading of some operators for which overloading should be forbidden, because the compiler should be able to generate them for any custom type in a way that would guarantee the expected operator properties and there is no advantage in allowing the programmer to implement those operators with functions having a different behavior.
While criticizing the excesses of C++ is fine, forbidding operator overloading completely makes a programming language unsuitable for some applications.
Operator overloading is nothing new, it has always existed for the base types provided by a language, since Fortran, then it was proposed for user-defined types in 1964 by John McCarthy and then it was allowed in various languages before C++, e.g. Algol 68 or Ada.
The aversion of the Java authors against operator overloading, which was very explicit since the first Java presentations, is quite weird because it is inconsistent with the Java love for OOP.
The essence of OOP is dynamic overloading caused by inheritance, which has the potential to be much more confusing than the static overloading of operators.
If I see an "object + object" I might not know what the "+" does, but I can find by searching in the source code. When I see an "object.plus()", then the possibility that the member function does something completely different than I expect is much higher, because the actual function that is invoked will be determined only at run time.