Alan Kay was also fairly specific about what he meant by encapsulation, and it's not just making things private. For example, he wrote, "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." And, later in the same paper, "Human programmers aren't Turing machines—and the less their programming systems require Turing machine techniques the better."
Java's programming culture tends to favor a shallower approach to OOP that cleaves very closely to the fiddly, imperative, state manipulation-oriented approach that is emblematic of procedural programming.
A great example of this is Java 8's streams API. There's absolutely no way to evaluate a stream without introducing a state change that will alter its behavior. Which means that, unlike for almost any other comparable API in another language, you can't safely pass around and share instances of Stream for fear that someone might break it on you. It's the shallowest possible interpretation of the abstraction in question, and making it that way was a deliberate decision that motivated by the tacit understanding that Java programmers have a fundamentally procedural way of thinking about the world, and would be confused by something that was truly declarative. The only other language I'm familiar with that takes the same approach is another popular "procedural programming with objects" language, Python.
This isn't to say that people can't do principled object-oriented programming in Java. Just that few people do. In part because, if you try, you'll end up constantly picking fights with the JDK. Not entirely unlike how you can do principled functional programming in Java, but it's an uphill struggle.
