Operator overloading is awesome in a functional language. Haskell allows for a lot of creative stuff with operators, but since they can't have side effects, must conform to predictable types, and have specific requirements they are somewhat understandable. Idris is also very ergonomic when it comes to operators.

C++ allowing a library to override the + operator with system("rm -rf /") is a lot less awesome.

Every time I use a language that doesn’t have operator overloading I wish I was using C++. It’s absolutely maddening to have to read and write things like “end.subtract(start)”.

As a computational physicist, I appreciate operator overloading IF used properly.
Example of a good use: + for matrix addition
Example of a bad use: left shift operator << as a pipe
I still don't understand who's in the C++ committee that they would choose this garbage over a function

Clearly you’ve never had to read code like

entity.position = vector_algebra::vector2_add(entity.position, vector_algebra::vector2_scale(entity.velocity, dt));

Honestly, I'm glad to have them, it can make a number of things simpler. For instance, a program I wrote had a number of duration fields that had to be stored in XML files and updated every once in a while. It was something that had to occur very often in the code: add a value to the duration, set that value in the XML data, and save the XML file. So I created a class that stored the date/time value and a pointer the XML element (it could be assumed that nothing else would be changing the value in the XML file and if it did, then that change should be overwritten) and overloaded the += operator (among others), so then all I needed was to create the DurationField object, and then I could go durationFieldX += time2 - time1 for instance. I could abstract all the logic away and make it very clear and easy to write. Could I have made it so that I have to to durationFieldX.add(time2 - time1)? Of course I could have. But IMO that variant is less neat and less readable.

Like all of the footguns in C++, it's only a problem if the codebase uses it wrong. When used correctly (i.e. only when behaviours mimic built-in types, and without side effects), it helps makes code more readable

Don't do what numpy does, which is to define * for two arrays. Without learning the library, you wouldn't know whether this performs element-wise multiplication, matrix multiplication, dot product or cross product. Worse yet, it behaves differently to Python's built-in * for lists (which is also bad), which concatenates N copies of the list