Supongo que está hablando de métodos públicos, privados y protegidos aquí.
Si es así, entonces no existen por razones de seguridad. Existen con el propósito de facilitar o garantizar que el software esté correctamente modularizado. (Si tienen éxito en eso, es un debate que dejaré para otros. Sin embargo, esa es la visión de para qué sirven).
Supongamos que entrego una biblioteca, luego tengo la libertad de entregar una versión diferente de la biblioteca y cambiar las cosas marcadas como privadas tanto como deseo. Por el contrario, si no hubiera marcado esas cosas como privadas, entonces no podría cambiar ninguna parte interna de mi software porque alguien, en algún lugar, probablemente acceda a él directamente. Claro, en teoría es su culpa por no usar la API documentada. Pero el cliente lo percibirá como culpa mía de que mi actualización de software rompió su software. No quieren excusas, quieren que las arreglen. Pero, para empezar, si no les dejo acceso, mi API es exactamente el método público que pretendía ser mi API y se evita el problema.
La segunda cosa más probable de la que podrías estar hablando es el modelo de seguridad de Java. Si está hablando de eso, entonces la razón por la que existe es que la visión original de Java involucró a personas que envían posiblemente applets que no son de confianza para que trabajen interactivamente dentro de programas de terceros (por ejemplo, navegadores). Por lo tanto, el modelo de seguridad estaba destinado a brindar a los usuarios cierta protección contra los applets maliciosos. Por lo tanto, la amenaza de seguridad de la que preocuparse y de la que debe protegerse son los applets no confiables que intentan interactuar con otro software que podría estar cargado.