I do care and I read this with interest just now. The idea that it took three hours to write a review of a month+ of work as part of "professional development" and that this person must bear that costs of that education, is a tip of the iceberg indicator to me as to the difficult work world we live in today. How is it that capital owners make money while sleeping, while craftsmen intellects spend a month+ without compensation to "get up to speed?" I am on the tail end of this after decades and it jumps out for me now, past the OOP part.
Second - I learned OOP approaches long ago, have written a lot of software and have used OOP in my own ways, much like this author. I appreciate the effort here! It is an interesting, technically somewhat shallow (no code in this essay) yet as noted, good balance of critical and open mindedness.
I do not understand OOP-hatred past "I hate the music my parents liked" and "Java is so tedious that it makes me hate all of the whole structure of it".
I used OOP code myself to separate parts in loosely coupled systems of several flavors; to make a systematic ordering of commands, to enable scripted or menu-driven command sets; and to wrap an interface around data for the convenience of other code. I feel that a strong point of OOP is to REDUCE the cognitive load for the human. Yet many snipes in articles about OOP specifically complain about the lengthy, spread-out, tedious nature of OOP code. Your mileage may vary ! Use it badly or use it well .. its not my doing.
The specific kind of software system described in the third book here, with messages passed without state between objects, is interesting, and reminds me to say now: I think there is vastly insufficient distinction made between software solutions, their design and implementation, in OOP criticism. What are you trying to solve? How much persisted data is there? or state, or interface to XYZ external system. This matters in design choices and I feel like OOP-critics often race to their favorite annoying thing rather than do the intellectual work of distinguishing for a reader, what the assumptions are and what the finished product requires..
Overall, this essay is worth reading, feels short to me despite obvious effort on the part of the author, and personally, I get a nagging feeling that people doing this kind of work should be less scammed by low-morals middlemen and more valued socially for the architects of software that they are.