There are limited, specific situations where field visibility has an impact. I am talking about Java applets. An unsigned Java applet can only do limited system interactions (no access to local files, no connection to external servers except the one which served the applet code, and so on). These restrictions are enforced through a complex framework of "permissions" which is implemented... in the Java code of the standard library.
If an applet could access private fields of arbitrary Java objects from other packages, then it could fiddle with the objects and tables which define the current permissions for the applet itself. In effect, the right to use the reflection API on all classes (including system classes) technically grants all rights to the applet.
This does not mean that the field visibility keywords like
protected are a security feature; it means that the designers at Sun/Oracle used field visibility to implement and support a security framework (and, in my opinion, they should have done it otherwise, because doing it that way is like trying to maintain a black list of "dangerous calls" on thousands of possible calls, and it is very hard work, and the recurrent apparition of Java 0-day exploits is a testimony to the hardness of such an approach).
For most other situations, object fields should be made private because it promotes better software engineering practices, making for code which is easier to maintain (like all rules, that one has exceptions; occasionally, a public field is a better idea). There is nothing about security here; it is about usability and maintainability.