At the risk of turning a unison into a chord, here's my two cents.
If:
1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore.
2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend.
Then write code that is easy to extend, not delete.
The question is whether your impression of the above is true. It won't be for most junior developers, and for many senior ones. If orthogonality isn't something you preoccupy yourself with, it probably won't be.
In my experience, the most telling heuristic is rewriting propensity. I'm talking about rewriting while writing, not about refactoring later. Unless something is obvious, you won't get the right design on the first write. You certainly won't get the correct extensible design. If you're instructed to write it just once, then by all means make it easy to delete.
Here's an algebraic example to keep things theoretical. If the easy to delete version proposed by the article is:
f(x) = 6x^2 - 5x + 1
The prospective extensible version is:
g(x,a,b) = ax + b
f(x,q()) = q(x,3,-1) q(x,2,-1)
f(x,g)
It's the generalization for factorable polynomials. It's clearly harder to read than the easy to delete version. It's more complex to write, and so on.
However, it's algebraically orthogonal. It has advantages in some cases, for instance if you later add code for a 6th-order polynomial and need to use its zeroes for something else.
We know that it could be better in some cases. Is it a good bet to predict that it will be better overall? The problem domain can fracture across a thousand orthogonal "creases" like this one. The relevant skill is in making the right bets.
Here's an example that's not orthogonal. Let's say we think the 6 coefficient might be more likely to change in the future:
g(x,a) = ax^2 - 5x - 1
f(x,q()) = q(x,6)
f(x,g)
This version is most likely just adding complexity. A single function is almost always a better bet.
If:
1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore.
2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend.
Then write code that is easy to extend, not delete.
The question is whether your impression of the above is true. It won't be for most junior developers, and for many senior ones. If orthogonality isn't something you preoccupy yourself with, it probably won't be.
In my experience, the most telling heuristic is rewriting propensity. I'm talking about rewriting while writing, not about refactoring later. Unless something is obvious, you won't get the right design on the first write. You certainly won't get the correct extensible design. If you're instructed to write it just once, then by all means make it easy to delete.