Let's start from scratch. First of all, what indeed is abstraction?
When you program, you often have to solve very specifically detailed problems.
The primary motive for abstraction is when you might find yourself at a situation where your program handles the whole problem as a single unit, with many discrete little peculiarities that require attention and understanding. The problem here is that it it's hard for human beings to handle such huge amounts of data at once.
The Solution: Abstraction
In order for you to be able to understand just what you need to in order to implement your idea, you extract detailed solutions into simplified abstractions.
For example, let's look at ORM (Object-Relational Mapping), where SQL is abstracted into objects.
In order to insert a new item to a database without abstractions, a programmer has to know SQL. So to insert a new item a programmer needs to remember the SQL syntax for inserting a new item into a table:
INSERT INTO Items (field1, field2) VALUES (value1, value2)
But with abstractions, the programmer only needs to be aware of the idea of what he wishes to do. An object-oriented abstraction might look like:
Item item = new Item(value1, value2)
You can even go a bit further and think about the fact that SQL itself is a huge abstraction for tons of sophisticated data-storage structures and algorithms, which are fully at your fingertips for the price of learning a simple declarative language.
The Opposite of Abstraction
Based on what we now defined that abstraction is really all about making it sufficient to only know the quintessential concept at hand, we can easily deduce that the opposite of abstraction is in fact esoterica, where usage or understanding entails having some sort of specialized knowledge of the subject's peculiarities.