Abstraction is a basic principle for dealing with life, never mind software. For instance, imagine you are keeping track of bowling scores.
Well, you probably use the abstraction of "integer". Integer is overkill however because it can be negative, and could possible take an infinite amount of space to represent. Practically you might write the scores by hand with base-10 arabic numerals and you know how to execute an algorithm for abstract operations such as "addition".
Doing it on a computer?
Bowling scores can be as high as 300 so a "int8" is not quite big enough, but a "int16" is just fine and you wouldn't care if it was signed or unsigned.
In the 1960s you would learn how addition is implemented in circuitry if you studied computer science, today you might not -- you don't need to because Intel or ARM did it for you.
If there is a real problem with "Paradigm X" where "X" could be "OOP" or anything else, is that software tends to reify one particular view of a situation whereas different people involved in the situation see it differently.
It is not some glib mantra like REST or SOLID or SCRUM that you can repeat over and over again and imagine that you understand something.
It's about the gap between the map and the territory which is the most mysterious and confusing place in the universe. (e.g. the "Dark Matter" is there)
Fast-forward to 2019 and OOP is on SOLID ground:
S - Single responsibility principle
O - Open-closed principle
L - Liskov substitution principle
I - Interface segregation principle
D - Dependency inversion principle
I would argue that abstraction is the base principle of all programming and really isn't terribly useful principle with which to differentiate OOP.
It does no harm to reference the GoF that perhaps the same G. Booch is associated with:
Design Patterns: Elements of Reusable Object-Oriented Software
Replace word first thinking with thought first thinking and you’ll be fine.