That’s the definition of private, that only the declaring class can access. I believe the main beef is that one object _can access_ another object, even though they are the same type. That makes perfect sense to me. How else would equals and hashcode work?
I desperately need better nomenclature, but it is essentially what I think of as "implementation hiding for security and reliability reasons". You specify a small-ish set of methods that depend on the internal state of only this object, you verify their goodness, and then calmly implement all other operations in terms of those.
Then Java is based on "implementation hiding for maintainability reasons" -- i.e. it's really important that if you refactor something private in a file, your commit should only have to mention that file, and no other file can depend on private members in other files.
In this case, the "reliabiliy" perspective confers greater maintainability, at least in one dimension. On the other hand, much lower flexibility, as several people have mentioned already.
In some loose sense, it's the distinction between a syntactic perspective (boundary crossing happens at the file level; the characters on screen determine what implementation hiding means) and a semantic perspective (the objects should occupy an utopia where they do not distinguish between each other based on class, if you excuse the pun. What matters is their allowed behaviour and that interaction.)
I am afraid I have failed to express this in neutral terms because of my preexisting biases, but I hope the idea comes across anyway.
It also makes perfect sense to me. Visibility is type-based, not instance-based. But to answer the hypothetical question: one would have to introduce class-private (package private?) getter methods for all relevant truly-private fields. I'm happy that's not the case.
"protected" stuff can be accessed by classes in the same package, even if they not inherit the class with the "protected" member. I find this very annoying as I use protected and package-private for entirely different semantics.
No scope qualifier means package-private for classes and public for interfaces. I never could wrap my head around this. That's bad user interface design. As well, I have package-private interfaces sometimes (which is perfectly possible), but their methods can only be public (which is unwanted if the interface is package-private).