"Don’t use classes" is not what I meant. It’s "don’t create abstractions”. Create the literal thing you want to create, in any way (though preferably somewhat organized), then maybe think about making it cooler.
It also wasn’t supposed to be advice. (Not sure what you mean by TFA.)
By the definitions I'm familiar with, functions would be abstractions of program segments, and variables would be abstractions of program data.
With that understanding, the closest you could get to writing a program without creating abstractions would be to write in assembly—but even if you opt to use as little abstraction as possible, you may just get further from your original recommendation to "Create the literal thing you want to create":
I can see a couple ways of interpreting that statement.
1) Imagine what you want to create already existed: what it would literally be is a block of machine code, so when you write your program you should make it as close to that hypothetical literal existence as possible.
2) What you want to create doesn't exist materially, so its only literal existence is a set of high-level domain-specific concepts (i.e. its existence is a spec), in which case the most literal way to represent it would be through a set of matching high-level concepts defined through a programming language, i.e. a set of matching abstractions.
Under the second interpretation at least, it requires heavy use of abstraction in order to implement the spec as literally as possible.
I think they mean something like abstract base classes.
It's tempting to design a class hierarchy from first principles: everything in the game is an entity, from which players and NPCs are derived. The NPC base class has several derived versions (allies, monsters); the monster class is specialized into animals and dragons, which in turn....
You can often paint yourself into a corner this way, where you suddenly don't want the dragon class to reuse part of the MonsterBase. They're suggesting making the classes stand-alone with duplicated code, at least until you figure out what these classes actually have in common and what is incidental overlap.
That's why designing the actual program is important. Also, static and strong typing for powerful refactoring plus extensive tests, and you can refact that Dragon class into something new.
And while I do agree with you, I think it is not OOP that's bad but the programmer doesn't understand when to do inheritence vs composition etc
It also wasn’t supposed to be advice. (Not sure what you mean by TFA.)