That something can be described in a procedural manner does not imply we humans work that way, nor does it preclude the fact the those same things can be described in other manners as well.
When you interact with other people, you do it the OO way, you send them a message and they either act on it or not depending on their own internal state with different people able to respond differently to the same set of messages; I can just as easily claim we humans work in OO ways.
Beyond that, it's easier to describe a sequence of steps in OO where the implementation details can be hidden and swapped out with different implementations than in procedures where the logic and implementation are all mixed together and tightly coupled.
What you're used to seeing might be better described as "class-oriented programming", i.e. Java's take on OOP. Once you realize that `this` is just an implicit parameter and objects are just closures (look at Javascript's OOP for a good illustration of this principle), and you start to think about how objects can interact reliably across interfaces/languages/networks/failures, you more-or-less inevitably end up at "message-oriented programming", i.e. Smalltalk's take on OOP, wrapped up in declarative/functional APIs.
Disclaimer: these ideas are all unoriginal and some of them directly borrowed from other commenters in this thread.
Not really, they're more functional, they have textual input and output, and can be chained together, but they don't really trade meaningful messages back and forth. Processes can be thought of as objects, and signals as messages, but the set is not extensible while OO allows the developer to define the messages.
What definition are you used to seeing? I'm a Smalltalk'er, OO has been since its creation, about objects communicating via messages while hiding their implementation details so different implementations can be swapped in, i.e. late binding, polymorphism, and encapsulation, that's rather the entire point of OO.
C++ was C with objects bolted on badly, it'd be hard to point to a worse Object Oriented language. Smalltalk is what OO was intended to be, everything else is a bad copy.
When you interact with other people, you do it the OO way, you send them a message and they either act on it or not depending on their own internal state with different people able to respond differently to the same set of messages; I can just as easily claim we humans work in OO ways.
Beyond that, it's easier to describe a sequence of steps in OO where the implementation details can be hidden and swapped out with different implementations than in procedures where the logic and implementation are all mixed together and tightly coupled.