Oh, that's absolutely true--but in OOP as practiced with deep inheritance trees (as distinct from, say, actors with internal functional implementations), it's not just possible but indeed is the preferred way of doing things.
I'm not saying that it is wrong or even unnecessary--but the parent criticism was that it seemed more complicated than it had to be, and that it could often be more important to look at the data instead of the objects. I agree with that criticism.
As for problems, I'll agree with my sibling poster--just because two things are academically equivalent doesn't mean that they are practically equivalent.
Consider the link to Acton's talk...a lot of the testing and method calls are redundant or can be pulled out at a higher level, and encapsulation doesn't really win you anything because you know the problem domain concretely.
Numerical code is another case where OOP doesn't quite get you there. If you're just finding the average of a list of numbers, is it more sensible to have a function which maps elements of the space of lists of numbers into a space of scalars (which happen to be averages), or to have a list of numbers object that happens to know how to answer the "what is your average" message?
Now, let's say you wanted to represent a new space only of elements consisting of averages plus some offset. That's again trivial in a functional language with currying, but in OOP is kind of awkward.
The reason we like functions is because they represent a straightforward mapping from one space to another, and can be implemented very performantly. OOP principles, especially encapsulation, require that a function cannot know about the internals of the object it's working with, because it should be able to be changed out at a moment's notice.
It is also because of the requirement of functional programming to know concretely the details of the things passed into them that we see such demand for static and strongly-typed and immutable systems.