The flaw here isn't OO, but the idea that it should be applied in all cases. The point of OO methods is to control access and mutation of an object's private members. Rather than have clients know to, e.g., lock specific fields before accessing, you expose a method that handles the locking appropriately.

The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (including the original programmer at a later point in time!) in understanding the code. There are tradeoffs to using "method" syntax as well, but to me that mostly is an argument for having both options available.

There is the most important argument regardless, whether it is a method or regular function - first one (or last one in languages supporting currying). While it's true that there are functions with parameters of equal importance, most of them are commutative anyway.

But if you make it thingService.doThing(x,y) you're all good.

Excuse me, you need a BeanShell.BeanThread.GeneratorStalk.VeggFactory to do that in this Environment®™

There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do.

(also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)

Yeah, the dot operator is not a particularly strong signal of whether something is OOP or not. You could change the syntax of method calls in OO languages to not use the object as a prefix without the underlying paradigm being affected.