I think this can reasonably be described as a footgun rather than a bad design. Instance methods should relate to the state of the instance. If they don't that's a poor design choice. This is a pretty easy code smell to reject in code review.
Perhaps Java would be cleaner if it had free functions. But this isn't so different than a big class that has a pile of static methods.
C++ also addresses the "you have to wonder what members might be read or written inside the function" by encouraging the use of "const" as much as possible. You get really nice invariants preventing surprise state changes in receiver objects and other parameters through judicious use of "const", even if everything is a class or object.
> This is a pretty easy code smell to reject in code review.
It is if the code was reviewed. If, OTOH, it just grew until something needs to be done (like the object with 60 public methods that I'm currently trying to refactor), you can have a devil of a time unpicking it.
The same could be true where free functions are preferred, but it seems that most programmers seem to have grasped the idea that global variables are hard.
> by encouraging the use of "const" as much as possible.
I'm a big fan of const-correctness. I haven't written C++ in years, but I always used to love putting 'const' everywhere.
But that's the point I'm trying to make - Over my career, I have inherited bad code in both styles - "prefer objects" and "prefer functions". In my experience, bad objects tend to be a nightmare. Bad free functions tend to just be a bit annoying.
There are only two ways in which code review can keep your codebase clean in this situation: Stop doing any other development until it's all nice, or invent time travel.
Perhaps Java would be cleaner if it had free functions. But this isn't so different than a big class that has a pile of static methods.
C++ also addresses the "you have to wonder what members might be read or written inside the function" by encouraging the use of "const" as much as possible. You get really nice invariants preventing surprise state changes in receiver objects and other parameters through judicious use of "const", even if everything is a class or object.