I absolutely agree that total and consistent encapsulation would be great, however, realistically it isn’t going to happen.
Ideally new systems would be written encapsulated, but just as you find it a bit confusing to come in to inconsistent code, people working in existing code that isn’t encapsulated feel strange being the only piece that is encapsulated and tend to follow the pattern of the code they are working in and so a culture of encapsulation is hard to build.
Existing systems will occasionally be encapsulated to allow better control over the members and to ensure necessary side-effects are managed, however, changing the entire engine would be a massive undertaking that would distract us from being able to do anything new for quite awhile. It would cause untold hours of work to users of the engine when they integrated that system. And in some cases, particularly BlueprintReadWrite variables, require new tech to allow us to redirect the existing nodes to using the setters (which honestly is something we need to do anyways, but still more work).
As TheJamsh said … this is the product of an engine that has 15-20 year old code and many systems were originally written in unrealscript where encapsulation could have a non-trivial runtime performance cost.