i’m afraid i have to disagree.

a program is a representation of the stakes at hand. the issue is logic: you are going for a logical structure that matches that of the problem space. whatever the outcome you are going to make it work, but sustainability relies on this isomorphism.

inheritance is a property of the world, hence its usefulness. multiple inheritance (that’s how it’s calledd) also is but raises questions — in the real world too (cf. biological systematics). IMHO, languages should allow it and leave it to the programmer to handle the issue. if you’re confronted to complexity, your program must be complex.

reuse makes sense within context similarities. you already have a better reuse ratio within a large program if you go OOP, but you can’t expect a class to behave the same in a every different semantic field.

OOP doesn’t have to be a religion. functional tools are always handy.

encapsulation is the application of the logical paradigm of OOP. it enables the programmer to model the program after it’s target. there are security issues in the world but that’s not what encapsulation is for and that’s not how to solve them. this “passing by reference” obsession is irrelevant.

and polymorphism is not really a specific property of OOP in the first place, as you say yourself — not one of the OOP key selling points at all, if you will. so your inital breakdown is a bit biased.

i understand younger people may feel that they’ve been fed OOP at school or in work settings with too much radicalism and too little common sense. that’s ok, it’s only healthy to question traditions. but a programmer who likes his job is sensitive to the formal consistency of his production and will sooner or later realize that, although OOP doesn’t have to be hegemonic, it can’t be avoided either.

cheers.