I disagree as well. Abstractions, or interfaces, define the contract between modules, and then you can reason about the system in terms of those contracts. Without the abstractions, you’d have to reason based on all the details of the whole program, which is obviously much harder. Abstractions are a form of divide and conquer.

Regarding the article’s point about diluting abstractions when new disparate features are required, a third alternative (to the two presented in the article) is often to provide alternative abstractions in parallel, each individually still focused and to-the-point, which prevents both changing and diluting the existing abstraction.

Regrading the article’s point about performance analysis, in principle you can specify performance guarantees for each abstraction. It’s more difficult to check them, but in theory a type system could even encode performance characteristics in an automatically checkable way.