I'd argue that, it's not remotely the most important part nor is sub-typing. Encapsulation encourages better OO, but you can take a well encapsulated OO program, and remove all encapsulation by making all the data public, and that program is still a well structured OO program. OO is about the way objects talk to each other to accomplish work, the message, the API between objects; it's not about the many little things like encapsulation that encourage better messaging. There are dozens of practices that encourage better OO, but you can write good OO without them if you know what good OO is and don't need those training wheels.
Well, now we have to get semantic; if by encapsulation you mean you keeping your data private and only exposing behavior publicly, then you're wrong. If by encapsulation you mean all behavior that uses an objects data is in the object and no outside code relies on that objects data even if it is public, then you're agreeing with me.
You clearly didn't play out my thought experiment above or you wouldn't be making the statement you just made.
I agree that in your thought experiment, the program remains OO, but the language is not. You can write OO programs in many languages, but I would argue that you don't have an OO language unless it has special support for OO programming.
I wasn't arguing it was an OO language, merely that it was OO code. OO used to be done in C in exactly the same basic way, passing the struct that is the object as the first arg to all the member functions; Python does this explicitly as well.
