Please don't treat me like an idiot. I've been studying OOP concepts for quite some time now. I'm quite capable of figuring out any deep concepts you care to throw at me. If you can't explain them in your own words, fine, but don't expect me to believe you have any real insight on this question because of that. I could watch that whole video and still not know what you were trying to argue.
Doing OOP in languages like Java and Ruby tend to involve classes, objects, encapsulation and state coordinating. Now, the truth is, state is really hard to maintain. You have this piece of information where everyone is trying to change or grab at, it's gonna end up leading to race conditions and locking. It may work for a small app, but as your application scale up, it's a maintainability disaster. So you said OOP done right helps. But, OOP was the wrong paradigm to begin with, it's like saying "Horse-riding done right gets you anywhere faster". I'm not saying everyone who has been programming in OOP is wrong, it totally makes sense to use OOP because it's easier to model real world things with. But no one has ever question, "This paradigm may be facilitating my understanding of the problem, BUT is it the right paradigm?"
> You have this piece of information where everyone is trying to change or grab at, it's gonna end up leading to race conditions and locking.
Why is everything trying to grab at state? I call information that everything wants access to 'data', and I manage that accordingly. Each application interested in it grabs the data, preferably stored in a database selected specifically for the needs of the data and how it's accessed, parses it into objects, does the operation it needs to on it, and then perhaps writes a new record of data. The objects can go away as soon as they go out of scope, leaving the data available to construct a new object when it's needed.
People say to store state in a RDBMS, I think that's ridiculous and a perversion of OOP. Program state belongs in memory, not on the network. It's not intended to be tabular, an object's state often consists of references to other objects. I sure hope you're not storing these in a database.
An object's state is only supposed to be accessible through it's interface. It's bad OOP to have other parts of the program interrogating its state directly. It's bad OOP to have an object interact with more than a few other objects. If you find yourself violating that, then you're treating data as state and you need to start managing that data separately, through a persistence layer.
Maintainability means being able to alter a program's behavior without having to understand the whole thing or make drastic edits. If you follow the rules of OOP and don't just say you're doing OOP because you're using classes and stuff, then you'll have earned maintainability because you'll be able to change a class's internal behavior without affecting the rest of the program because it's using an interface rather than needing deep knowledge of the altered class. And you can change the interfaces too, only changing the two or so other classes that use them.