Good editorial, and a very good point about techniques not officially supported against alternative (supported) methods.
One minor niggle some extent it reads as if defensive programming is only about doing a calculation (on a subset of the data) two ways and checking the results are the same. It isn't. One of the first steps is to make sure you have code for all the "this can't happen" situations; another is that you validate every input; yet another that you use recovery blocks, in multiple layers. Then there are domain-specific defensive coding techniques too: for example getting the correct order of computation to minimise the effect of rounding errors and of course that sort of calculation has to be done two ways on all the data not on a small subset, since a small subset won't produce runaway error accumulation; and if the two result sets are close enough for safety, taking average values over the two sets may be a good idea - for some definition of average.