“OOP” is one of those terms (like most terms) that have a narrow meaning and a broad meaning, and either proponents or detractors can use one of them in arguments:

• OOP, narrow sense (emphasis on “object”): data-with-associated-functions, encapsulation, etc.

• OOP, broad sense (emphasis on “oriented”): organizing your program around objects that model the nouns in the problem domain, “everything is an object”.

A (satirical) illustration of the latter is in the first few paragraphs of https://caseymuratori.com/blog_0015 (from 2014), which gives an example where, to write a payroll system, you first start by designing classes for “Employee”, “Manager”, etc.

A (non-satirical) illustration is in the infamous “TDD Sudoku” series of blog posts (follow the links from http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... or https://news.ycombinator.com/item?id=3033446) where (in contrast to Norvig's program which just solves the problem) the TDD/OOP proponent ends up with a “class Game”, “class Grid”, “class Cell”, “class CellGroup” (with derived classes “Row”, “Column”, and “Square”), but ends up nowhere. (From Seibel's post: “…got fixated on the problem of how to represent a Sudoku board. […] basically wandered around for the rest of his five blog postings fiddling with the representation, making it more “object oriented” and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem”.)

I think we can agree that this sort of object oriented programming can hurt a lot (thinking about objects is not a substitute for solving your problems, though it is tempting), while objects themselves are useful.