OO is not "just a tool", because it's often coupled with a language. A wrench is "just a tool" because I can always reach over for my socket set if that seems to fit better. Once I'm in Java, I am locked into a whole ecosystem and Java work hard to make sure you write OO code. I can't just reach for a lisp halfway through if I think that tool would work better.
IMHO, The biggest problem with the oft-repeated meme "just a tool" is the word "just". It dismisses out of hand the powerful ways in which tools (e.g. media) nudge us in certain directions and shape the way we work. Any time you hear someone say "just a tool", you are talking to someone who considers themselves cognitively separate from the tools they use, whereas in reality there is something much more fluid happening.
Let us not forget that tools themselves are designed, and some designs can be downright pathological. A kettle is a tool for making tea, but (in deference to Donald Norman) there is a reason we don't make kettles with the spout on the same side as the handle. Just because someone designed a tool to solve a particular problem does not mean that it's the best way to solve that problem. We can and should be critical of our tools without emotional attachment to them.
I disagree, as seems most commenters do. Sometimes OO is tightly coupled with an language (Java), and sometimes not (JavaScript), but that's just part of the consideration to be made before choosing which tool (language, OO/procedural) to select for the task at hand.
Once I'm in Java, I am locked into a whole ecosystem and Java work hard to make sure you write OO code. I can't just reach for a lisp halfway through if I think that tool would work better.
Yes, and I've done that before. However, there is still overhead in switching underlying data structures when switching between the two and making sure you don't break the STM among other things. It's hard to share data models between the two.
No, but I am saying that switching between them is not as easy as grabbing a different tool. The easiest place to switch languages is between abstraction layers or between functional components/processes. These language separations do not often coincide with the types of code that benefit from either OO style structure vs functional data processing.
