I think the parent was saying that private/protected aren't used to protect secrets, they are there to make code more maintainable when you have a split between

I think the parent was saying that private/protected aren't used to protect secrets, they are there to make code more maintainable when you have a split between implementation details and stable/revisioned public api "contract". You want to understand exactly what code may be depending upon implementation details and limit it (encapsulation) for reasoning and maintainability. I'll give a counterexample of this being done wrongly - Java has a pretty common development pattern where up-front you make a member private, and then write pass-through getter and setter methods. This doesn't really provide much for maintainability, because you have started out needing to support arbitrary retrieval and modification from anywhere, and have likely externalized interpretation of the data the member represents.