LOL.
OO, the politically correct version of "G[O]T[O]".
So much OO code, so much spaghetti.
Compound classic OO programming with Javascript's bizarre notion of "objects" and we've come full circle.
Back in the 1980s and 1990s when the efficacy of OO was still being debated as to all claims of improved productivity, the only thing that got proved by studies was that in fact, rewriting something from scratch improves code. You can take an OO design and rewrite it in procedural code and come up with less lines, and less bugs. You can take a procedural design and rewrite it in OO code and come up with less lines and less bugs.
OO is not provably superior in productivity to procedural code except in people's dreams. As my advisor pointed out in grad school, computer languages and methodologies are akin to religion. Once people glom onto them you can't shake them loose.
A good programmer will be good in procedural or OO, and likewise a bad programmer will still be bad. It is only the hubris of academics that methodology fads, like Design Patterns, can make code more robust or pick your metric. They never prove it.
I'm involved in an OO redesign now where they are using a concept fad called a "blackboard". LOL. Which is nothing more than a finite state machine design where all long running state is passed around on the "blackboard". After years and years of "encapsulation", they have, in fact come to realize that having a bezillion object copies of what is in fact is GLOBAL data, (No, not global data, YES global data!), they are going to now have data un-encapsulated so they can serialize state of long running transactions. Every object copies everything off the blackboard and the updates it when they are done and updates the blackboard. Copies, copies everywhere. But because objects are not, in fact, using the data on the blackboard, serialization is problematic because processes with object copies of GLOBAL data are in unknown states of running at any given time. Blindly using encapsulation is an Achilles heel of many an OO design.
Your comment about over "object" achievement reminded me of this. Encapsulation is not always the right design if in fact the application doesn't merit it. But people get taught blindly, as with religion, that encapsulation is always good for all things big and small and you can never get enough of it.