The answer to the question at the end of the body is yes.
As Gerry said, the story about counting layers as a measure of abstraction doesn't hold much water for mathematics, and I don't think it works very well as a classification of programming language either. In fact, the point of explicit specification abstract of programming languages is that in principle you don't know at the time you write a program how many layers will be involved in executing it, as long as the topmost of them present the same interface to you. There certainly is an (informal!) hierarchy of languages that are more or less close to the raw hardware, but it cannot be expressed as crudely as counting layers.
It still makes excellent sense to think in terms of layers when understanding a computer system, but the number and identity of layers are not so well-defined as certain textbooks (or the infamous OSI reference model) would have you believe. And real life is ripe with instances where a "low-level" service is implemented on top of "high-level" services in underlying layers (protocol tunneling, simulators, virtual machines, virtualization, etc), which again makes counting the layers an extremely inexact science.
However, there's a quite separate concept of "abstraction" in software development within a single programming language, and that matches the mathematical idea of abstraction quite well. In both cases the idea is to explicitly decide on a small set of attributes of the thing under consideration that you care about, and then make sure that your work depends on those attributes only. The meaning of "abstract" in the mathematical idea of an abstract group is very close to the meaning of "abstract" in the programming concept of an abstract list type.
Certainly, mathematicians and programmers tend to have different motivations for using abstractions. In mathematics, the eventual reason for considering an abstraction is often to reach a better understanding of each concrete instance of the abstract structure, by using the abstraction to transfer intuition and arguments between its different instance -- whereas in programming, the instances of an abstract type are just tools, and the eventual goal is what we do with them. Here the reason for abstraction is simply to manage the complexity of large software systems, and make it easier to predict and contain the consequences of changing one piece of it.
But neither of these senses seem to be be directly relevant to characterizing pure mathematics as "strange" and "so abstract". Here I think the matter is that most of the abstractions that contemporary research considers look very unmotivated to outsiders. Outsiders have relatively easy access to the technical definitions -- you can go to Wikipedia and learn exactly what a left semi-symplectic Smith manifold over a topological division algebra is, but the article probably won't even attempt to tell you what it's good for. It can be hard to figure out even one example of such a thing that makes all of the conditions mean something.
For some reason, the motivation for studying things tends to be communicated among mathematicians in a much less structured and accessible way than technical details, and therefore it can easily look from the outside like the technical details are the motivation, complexity for its own sake. And even when you do dig down to find the real motivations, the study of left semi-symplectic Smith manifolds over topological division algebras often turns out to be just a link in a long chain of conjectures that after five or eight similarly arcane steps would lead to a proof of something intuitively interesting. (Here is something that could be parallel to your "layers of abstraction", though the relation between the various steps is not necessarily a well-founded "X builds on Y" kind of thing).