There is no such thing as "one true OO" or "real OOP". OOP is programming paradigm that combines a number of concepts together. Abstract data types, separation of concern, association of behaviour with data, virtual functions, etc. An OOP language provides good support for all of those concepts. A good programmer makes use of these concepts when needed, and not when not, there is no absolute "right" or "wrong" approach.

This is not an answer to the question. It is also extremely inefficient to use an iterator to find the last element in a list.

One concrete example is naming: the 'setName' function in a procedural language should actually include the module name: 'personSetName'. Otherwise it will lead to conflicts during linking. In OO languages you don't need to think about that. Anything that you don't need to think about makes programming easier.

You raise some good points, but your main idea is flawed. Yes, it is possible to implement OO concepts such as encapsulation, virtual dispatch, inheritance, and even garbage collection in a language like C. It is also possible to do that in assembly. It does not make programming easier. Programming and especially designing in a language like C is definitely more difficult than it is in an OO language. In C you need to map the concepts to their implementation, in an OO language you don't need to do that step (at least not for the OO concepts).

... and the code will never be changed after it was written ...

Agree with most comments here: messaging is most definitely NOT the key concept of OO. Just because it was the main concept in Smalltalk does not make it the main OO concept, the world has moved on since then. I would call encapsulation the main concept, virtual dispatch the second, and inheritance a third.

In swift 3, I get an error on both of these.

That is not a style in Objective-C, it is mandatory. In Swift you have a choice. "I have always done it that way in another language" is not a good reason to keep doing it that way.

All disadvantages you mention are due to very strange company policies, and not inherent limitations of a CVCS. Typically you can limit which users can merge into certain branches, every developer typically works on a personal branch, where you can commit as much as you like, and anybody can typically create new branches (for example if you run two development tasks in parallel).

"With traditional CVCS you either commit or you don't." - that's not true, of course. The normal way of working, on a personal branch, allows you to do whatever you like until your code is merged into the main branch. And the same way of working can in principle be used for "public or OSS project" with an CVCS, although I agree that would be more cumbersome.

+1, because it mentions the only valid reason for writing code documentation in another language than English.