The original author is looking at the part of the problem that gets the most attention, but not at the part that causes the most problems. He's looking at programming languages and their expressive problems. Those are real, but they're not why large programs break. Large programs usually break for non-local reasons. Typically, Part A was connected to Part B in some way such that an assumption made by part B was not satisfied by part A.
I believe the author ascribes most non-local problems to "incidental complexity". Incidental complexity introduces bugs, which in turn make code less predictable, which causes non-local problems. Furthermore, Grainger focuses on carrying out non-destructive data transforms, à la functional programming, which alone should wipe out a large percentage of non-local problems, as you shouldn't find yourself having to chase down any erroneous value-change bugs.
In fact, Grainger's whole point is about the attitude that you express being typical -- we focus on the fixing the problems created by the imperative programming paradigm within the imperative programming paradigm, rather than simply replacing the imperative paradigm with something more appropriate.
This essay is basically what all our CS lecturers have been saying for the last 40 years....