I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front.

In Python, especially. I'll find myself starting off all experiments or simple projects with functions and basic data types. As something evolves and I want some semantic clarity I'll stop using dicts and start using namedtuples. And then at some point I may replace the namedtuples with classes. From there I may discover value in having subclasses so I'll add a few (but this is exceedingly rare in my line of work).

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances.

No... I think this is missing precisely what was exactly the point of the article (see "(B)" in the text). This post is not a fight over OOP religion. The point of it is if you misunderstand or mischaracterize "nuances" about some idea (if these are actually all nuances, which I think is debatable) and propagate them, then you shield other people from prior (edit: or even current) literature in the area, and hence prevent them from understanding what the relevant techniques really are and how to use them properly at all. This makes them lose a potentially powerful tool in their toolset, which you should agree is an awful thing regardless of what coding 'religion' you follow.

OOP the Eiffel, Sather, Smalltalk, C+@, BETA, CLOS, SELF way isn't the same thing as most people learn in school as THE OOP.

Just like there isn't a single way of doing FP or LP.

Also lets not forget that all successful FP/LP languages are actually multi-paradigm and also include OOP concepts.

The great architect has the foresight on how the code will be used in five years and design it accordingly.

Isn't he better off taking that crystal ball that gives him the foresight, using it to pick the correct lottery numbers and simply retiring?

The great architect has the foresight on how the code will be used in five years and design it accordingly

Perhaps this is a function of me working in startups and consulting my whole career, but it seems extremely misguided, if not negligent for an experienced engineer trying to design for use cases five years in the future. Five months into the future is even pushing it.

What kind of companies operate in this way?

everything is made of bits

Bits are objects, too...

Structs are stack allocated and have no inheritance. But are otherwise syntactically work like classes.

Classes are heap allocated and allow single inheritance, unless the parent is an interface.

Interfaces are similar to a class but it's member functions must be overridden. A class can inherit from multiple functions.

I tend to use a mix of these and templates depending on the type of data i'm handling. I find it gives the best of whatever design pattern works well for different parts of a project without locking you into a certain paradigm throughout and still keeping everything fairly logical and coherent to read through and understand.