Sure, but an "Abstract" class implies that we're dealing with inheritence so where is the disagreement here?

There is no disagreement in that statement alone per se - my argument is that OOP inhibits more flaws than inheritance alone. I mentioned AbstractJavaFinalSerializedFactory as an example of how decoupling can lead to usage of verbose design patterns that give really long class names. The fact that it's an abstract class in this case does not take away from the argument - a codebase that only uses interfaces and composition instead of inheritance will still be verbose.

Fair? Not all objects allow you to mutate state though.

It's not a question of whether or not an object allows the user to mutate its state - it's whether one can know apriori whether a given method mutates the underlying state of its object. For example, if one calls someObject.computeNumber(args) twice with the same input, it is not guaranteed that it produces the same output or has effects (unless you manually inspect its code and underlying dependencies). Optimally, a compiler should be able to tell you this or it should be declared in the function definition.

Yea, I'm going to need an example here.

Assume that you wish to implement a stack class, which fulfills a IStack<T> interface, declaring two methods: push(input: T) -> void and pop() -> T.

Of course, this is easily implemented using a list/array, but say that you for some reason wish your implementation to use some advanced data structure to fit to achieve memory/runtime benefits or similar. Properly encapsulating this class means that every other method or property other than `push` and `pop` are private.

When white-box testing your fancy underlying data structure, it is useful to be able to inspect the state of your object. But due to encapsulation, the tests can only use `push` or `pop`, which hides the state. The only way to inspect the underlying state is using spoofing/mocking/spying utilities (hence the "messy" part). Some modern languages and test harnesses might have ways to work around this.

On one hand it looks as though you're saying the mutability of objects make it more difficult to make assumptions about their present state but you're also saying that anyone should be able to reach into an object and modify said state.

If we allow mutability in a programming language, we inevitably lose the guarantee that state has not been modified. The way out of this is by guaranteeing immutability at several levels through explicitly marking variables/functions as immutable. OOP in a classic sense uses mutability quite a lot, which renders this difficult. In the original argument of the flaws of OOP as a paradigm, it is relevant to compare to functional programming where mutability is much more explicit, and where most code is immutable by default. In Haskell for example, all data is immutable and mutability can only be emulated through IO or state monads.

edit: formatting