This post misses a crucial step in its argumentation: trying to understand why these abstractions happen. Blaming it on some kind of "techno-moral" decay is not an explanation, it only turns the argument into some kind of arrogant self-reward post. It's like when Plan9 fanboys argue about the lost "purity" of Unix.
The anecdote about these kind of security person is interesting, and it's not hard to sympatize with him, but he is missing the point: The industry seems to need someone to run these kind of pre-made security tools. These jobs are not pointless (perhaps they would be if the people who actually "know" other abstraction layers didn't create software that suck), they are solving some problem, people are working full time and getting paid for them. And the fact that they exist does not mean these jobs make sense or that the tasks they focus on are the right or the wrong abstraction.
> What good does an abstraction do when it breaks and nobody any longer understands how the technology under the hood works?
Not many programmers know of a kernel works internally (processes are just another abstraction). Not many know how compilers work and translate high level code to machine instructions either (there is probably no person in the world who understand all the parts of LLVM/GCC). The amount of programmers who know how CPU instructions translate to transistors is very, very rare.
Yet all these abstractions sort of work. People argued back in the day against programming in high level languages, nobody cares about these people, because the kind of problems that can be solved with high-level programming languages can't really be solved with assembly. Abstractions don't appear because companies are stupid, people are trying to solve problems with software and they need to get some concrete task done. Doing the quick hack does not mean that they are doing something wrong, it means that they are focusing into doing something right at another level. And if you can't understand that, it's _your_ fault.
Of course, plenty of times companies are doing stupid things, but that's the nature of the problem, companies try to do different things, some of them succeed, some don't, some succeed despite being horrible and some fail despite being brilliant on paper. So abstractions are created all the time, and there is a continuous dialectic between that abstraction and its usefulness, which is not measured by the opinion of other programmers, but by the success of the companies adopting and following these trends. For some people who knows a lot about systems programming and administration, it may feel stupid that these days we have people with cloud certificates who are in charge of "orchestrating" scalable and fault-tolerant platforms in the cloud, but know very little about how Linux systems work underneath. But it turns out that these people can get things working, even if they don't do it as well as you would do, and that's something that matters - it means that the abstraction sort of works, even if it leaks some times.
I guess it's not easy to spend decades learning things only to wake up one day and realise that large parts of your knowledge has been abstracted out and automated (ie. made less relevant, and thus less valuable in the job markets). But that's how things are in this field...