For something that argues against bad abstractions, the article sure is lacking in concrete examples and makes a point in abstract. A lot of people will likely misinterpret or get the idea that abstraction is only done for duplicated code (DRY as some people would call it). I think the wrong/bad "abstractions" here mostly refers to abstraction that was made over common code that is very specific in a context and is very susceptible to domain changes.

But there are a lot of other kinds of abstraction aside from DRY. There are abstractions made to reduce clutter and hide implementation detail and will likely be used only once. There are also abstraction that are more general and aren't coupled to the domain. These abstractions are more reusable and composable, and are immune to domain changes such as the step 6 in the article. Some people would find these kinds of abstractions harder to digest, but I personally consider these kinds of abstractions as extensions to the standard library, or even additions to the vocabulary of the programming language.

Note that I don't claim that general abstractions are necessarily better, since the generality can be made to the extreme and we'd have monads for breakfast.

All in all, I agree with the article, except that it is only referring to one kind of abstraction, although I hesitate to call it as such.