I'm not dogmatic on OOP vs FP, but let me take the side of FP here, we could model this as the car being a data structure with its position (x, y, etc), and a representation of what opening the door is (width of the car + length of the door, an anonymous function, or a named function, that can be made polymorphic) and now our open_door(car, world) can take both and the world doesn't need to know about what is a car and the car doesn't need to know about the world either, it just serves as a mapping, and the function open_door checks the positions of car in the world, transforms the car according to its procedure and checks it still fits the world and if not it produces an annoying beep.
So what you're saying is I'm going to have to downcast to a concrete class to figure out if my object is actually suitable for going to the store or my bathroom (my house isn't big enough to drive a car through).
Lines up with most OOP systems I've worked in.
To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking.
You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.