Nice, simple, article.

IMO, the main issue with DRY and other simplistic guidelines like the "rule of three" is that it lacks nuance regarding the "why" and the "what" of abstractions.

Putting repeated code in a single code or breaking up classes or methods into multiple due to the number of lines doesn't make for a good abstraction, sometimes it's just an indirection that's not really an abstraction.

I find that the concept of "abstraction levels" is a good guideline as to where to separate the code. The example given here is nice: have the business-related configuration in one level with the rows, and rendering code itself (that knows nothing about business part) in a deeper layer.