A better "functions should be separate from objects" is for the fairly common case where there is a function that takes arguments of two (or more) different classes as arguments; which class should that belong to? It gets even worse when the function is commutative.
Isn't that what multimethods are for? Multimethod systems (like CLOS in Common Lisp) allow you to specialize methods based on the types of more than the first argument.
Once you have multimethods, you don't need to couple the method definitions to the class body. But you're still doing object oriented programming; CLOS is an object system. The fact that people assume that OOP==Java is unfortunate, but doesn't change the fact that CLOS is also OOP.
Beyond that, I think you're conflating how method bodies are placed in a file with "belonging to a class". I can define C++ methods outside of the class definition, but surely no one would say that such methods don't belong to a class.
Well if 95% of the population use a term to mean one thing, then arguing that no it really means something else doesn't get you anywhere.
And no, I'm not conflating those. In C++ and Java, classes are, among other things, namespaces. When you declare a method in a class, it ends up in that namespace. Where it is defined is unimportant.
When someone says "object oriented" unless they define their terms, or are clearly coming from the smalltalk school, I assume they are talking about C++/Java style OO, since that assumption is right the most often.
This is particularly true when someone is talking about "what's wrong" with OOP
