> To me this is the most important part. I like to have private or public, protected is not needed.

OO's encapsulation is about bundling data and operation, not about information hiding, and as kazinator noted generic functions (as in CLOS) prove you can have OO just fine without.

As to information hiding, there are many fine OO languages which don't have it either (Python probably being the prime example there, but I'd say it also applies to languages like Ruby where you can trivially override existing ACL) so it's clearly not necessary either, let alone "the most important part". Especially as conversely many non-OO languages do have access control, hinting that the two are quite likely orthogonal.

Information hiding is useful for engineering and resilience, not for object orientation.

As to private / protected / public, I'd argue it's private which is the least useful (since we've already ascertained none is actually needed): it's literally just hiding stuff from yourself. I think removing that level of ACLs is one of the few good idea Go had.

ACLs also seem to mix concerns. The "private" concept is essentially making life difficult for yourself, but having a built-in mechanism for separating public interface from internal code, that's a bit more than just convention, is useful. For instance, in Common Lisp there's no language-enforced ACL, but when building modules (that may or may not involve a class, or many classes), I assign a package for each module and make it export only the symbols that represent its public interface. In code using that module, this becomes a syntactic difference in a way you refer to these symbols - module:foo means "foo exported from package 'module'", while module::foo means "foo internal to package module". That simple isolation, completely overridable with an extra colon character, is enough to clearly communicate what is and what isn't a part of an abstraction.

Is there a warning when someone overrides that isolation? In C# you can also access private members through reflection and I have seen people use that a lot instead of bothering to understand why the original developer decided to make the variable private.

No, there isn't, because "we're all adults here". But you have to type :: instead of : to do this, which usually tells you something, and you don't have to go through reflection to do this, so such overrides don't cause performance issues. Common Lisp doesn't prevent you from accessing anything.

I wish we he had more adults instead of people fresh from college who think that best practices and things to avoid are obsolete and don’t apply to them :)

That's the unfortunate nature of exponential growth. If the number of programmers doubles, say, every 3 years, that means at any point in time, half of the workforce has less than 3 years of experience.