I guess it depends.

I've worked on enough codebases that were made extremely fragile by "smart" people fiddling with (or worse, just relying on) notionally private variables, so I think encapsulation is pretty great. OTOH, I've worked on some fairly large scale js/ts where encapsulation is pretty loose, and 95% of the time it's not an issue.

In general, I find encapsulation to be a poor pattern and a symptom of OOP. OOP encourages thinking of concepts in terms of their thinginess, in which case it can make sense in that paradigm to do something like expose supposedly private data on an object through public methods. The need to conceptualize things in this abstract way is totally artificial, however, because it's often uncalled for and serves to just covering up the actual implementation details. Underneath the abstractions, we have data, and unlike in the physical world, that data is not fuzzy and full of mystery; there's a fixed number of flip-flop circuits in the memory hardware, and each of them has only two states. According to physical memory hardware, there are no "objects" or "classes". There are some tasks that are made easier to grok by designing them with object-orientation in mind, but most of the time thinking of things in terms of shapes of data is actually simpler.

The reason the "chanceOfRain" example is so revealing if this is that there's no reason to treat data like that as if it's an aspect of some entity with its own intimate knowledge. Why have this theoretical class wrapping around weather info as if we must ask a meteorologist? What's wrong with chanceOfRain simply being a function with weather data passed to it, or even just a piece of data that's already been computed by something? The latter options undoubtedly would result in less code and an identical outcome of data at-rest.

What's seemingly wrong with it is this idea you are referring to, which is that the authors of code must know better than the end-developers using said code. This mostly erroneous way of thinking is often justified as a means of preventing other developers from wasting their time doing something "incorrect", but the more distal reason is actually to prevent the code authors from having their time wasted answering questions by other developers encountering bugs doing things those authors don't approve of. Just like DRM, it only serves the authors and punishes fair use, while the "pirate" (in this case the pissed-off developer) finds a way to circumvent the system. If a developer is determined enough, they can write patches to get the behavior they want from the code the author attempted to lock away; in many cases, this is the most appropriate engineering decision since submitting a pull request is usually futile and inviting one's self into a debate with some rando.

There's of course other problems with private members on classes. In many languages, private members on a superclass are not available to the subclass extending it.

The worst part of all of this is how common it is for professional developers to subject their colleagues to this poppycock. It's one thing to try and prevent third-parties from doing "the wrong thing", but it baffles me how developers believe in making access to the "intimate" data highly difficult for other developers working on the same codebase. What the purple f***k? That data wouldn't be "intimate" if developers didn't blindly follow the theology of OOP; the only reason any data can be "intimate" to an object is if that object is thought of as a thing with behavior rather than as a shape of data. Someone may of course argue that encapsulation prevents entanglement, but it actually doesn't; entanglement is based on behavior, not data. At the end of the day, data is data, and your program is millions of bits in memory or storage, none of which have a necessary metaphysical relationship with one another. Behavior, on the other hand, is dependent on other behavior. You can hide away all your instance-specific data, but that will not* stop you from writing code that is highly interdependent. In other words, it doesn't make that much of a difference where you get "chanceOfRain" from, because entanglement doesn't stem from using the wrong data but by making things highly interdependent and not separating concerns. In other words, the argument that private members prevent entanglement is crap. At best, it discourages causing unexpected behavior and limits unexpected breakage, but even that doesn't always work given how common it is for breaking changes to be made to minor or even fix version changes.

In my opinion, data should rarely if ever be made private, and the only thing that might make sense to ever be made private is functions. Note that this suggests the exact opposite of "chanceOfRain" example. Obviously, not all behavior necessarily needs to be exported from a module, but just what is expected to be relevant to the end-developer. The beauty behind this approach is that it becomes a lot easier for an end-developer to patch the code or even just copy the code for functions they don't have explicit access to. Even better if the functions are pure* functions that don't rely on the state of module-level or global data structures.

So many problems would be solved in general if developers would knock it off with OOP and especially privatization. These are legitimate tools to have in programming, but their typical usage is a result of mass psychosis.