Regarding the first point, I know that in one project (embedded systems, about 2.5 million C/C++ LOC - what is that, the bottom end of large?), we tracked this rate of failure as well as we could. I would expect that we would always tend to under-report this because the relationship between defects and defect fixes was not something that was always apparent. But I do know that the organization tended to average around 15% failures and I wouldn't have expected a large number of incoming defects attributable to previous defects removal attempts that we missed - that is, we surely missed some, but I doubt it was a significant fraction. Following a particular process initiative (nothing fancy, just more intense review and testing of these changes), the failure rate dropped to around 7%. Beyond this, my experience in other, less formal, environments indicates (although I have no actual data to present) what I said in the article - that this rate might approach 20% but would not be expected to get anywhere close to 50% in general.

Regarding the expense of fixes, I believe what I said to be true - that expected exponential costs as a function of the time between defect introduction and removal would no longer hold exxcept at the extremes. Given that most iterative lifecycles embrace change that would invite this exponential expense (that is, over-turning the apple cart from requirements/analysis/design up for at least some portion of the requirements/analysis/design) and yet are nonetheless viable in their domains of applicability certainly suggests to me that they don't actually pay exponential expense in the general case.