When done right, object oriented programming (OOP) converts the imperative nature of procedural programming into a set of declarative entities with imperative calls within and between them. The advantages of better reasonability, reusability and all the others depend on this. However, I am yet to meet someone who is able to take full advantage of these properties at the outset. Most neophytes treat classes and the resulting objects as ad hoc containers of some state and fail to assess the underlying application's needs for persistent classes to capture. I had a colleague who wrote an 8k LOC class with every method acting on a set of instance attributes. Therefore, the benefits are enjoyed to the extent that one rigorously carries out a design that discovers the underlying classes. In other words, the barrier to the fulfillment of OOP's benefits are solely tied to one's ability to adequately elicit a design that accurately represents the domain. In the case of my colleague, he had not taken the time to discover the set of classes that would be acted upon by the methods resulting in a linear expansion of the class with every new feature.
And yet designing for OOP is extremely simple. Given that the goal of OOP is to represent the relevant entities as classes, then a quick traversal through the problem space should reveal these classes. This doesn't happen or rather happens to much less an extent than most tend to do so. From my experience, two reasons are responsible:
While the benefits are there, it takes many more years of programming to enjoy them. Effectively, this means that most people will not confer these benefits on users of their code until they have overcome the technical hurdles of both writing the required code and mastering the underlying concepts to make use of them.
Does OOP boost productivity? Not in the short run but if you keep at it...