I agree with you on this. The study is irrelevant from the statistical point of view.
However, there are other considerations with TDD, probably on a more theoretical level that:
* There is no other major engineering branch that uses testing this way in production (would you bang a car against the guard rail to see if it works?)
* There is one thing common for sure with all of the bugs you catch in production, they all passed the unit tests
I think testing has it benefits but driving(!) your software development efforts is probably too much, at least for me.
Car manufacturers model car bodies mathematically so they have a good idea how a body will behave before they build it.
This hints at why the philosophy of TDD is not as helpful as it seems: it confuses modelling/analysis with implementation.
Your testing methodology can be perfectly implemented, but if your problem analysis is wrong your software will still be useless and broken.
TDD would be more interesting if it understood the distinction between specific behavioural expectations (easy to test for, but incomplete), generic applicability and model robustness (much harder to test for, but more complete), and complete formal correctness (often unreachable, but always an interesting goal.)
TDD is better than nothing. If all you can manage is a set of behavioural tests, that should still improve reliability.
But it's a big leap from there to the suggestion that if you define your spec as a series of behavioural tests and your code passes them all, you have a full and correct solution for the initial requirement.
That is just plain wrong, and in untrained hands it can be dangerous.
To your first point, the usual response is that there's no other major engineering branch which demands quite such extensive changes be possible after you've broken ground. To extend your analogy a little, nobody takes a car production line and expects the people running it to be able to switch to helicopters without starting over.
I agree, and it does not happen to my projects either. We agree in advance on the set of features for a certain version and we deliver that. If you doing much car building when you actually need a helicopter than there is something wrong.
I mean, you do incur a cost for programming with TDD though. The benefits may repay the cost in the end, but the cost is still there. And for that matter cars do undergo destructive testing, just not TDD--and the problem there is presumably that the car benefits from taking a holistic component-driven approach, "here is what I want the car overall to look like, and what components I want to fit into the space inside, now how can I reduce the rollover risk?" rather than "here are some basic expectations of a car, I expect it to be able to move forward and hold a passenger, let's make the smallest thing which causes that to happen. OK now let's add a single passenger, and let's test that bugs aren't flying into your face at highway speeds so that we remember to add a windshield eventually. (1000 steps later) Crap now we're testing the ability to shift into reverse and none of my homespun bare-minimum engine design is going to work there."
TDD probably pays its best rewards with relatively simple well-defined projects, and needs to be deployed with a modularization strategy. Possibly the wishful-thinking strategy of top-down design would be a natural complement, since when you wishfully think of a function you can hopefully quickly write a test or two for it.
Your example posits an evil developer with a BOFH mindset. S/he is trying very hard to get away with doing as little work as possible while meeting absolute minimum requirements. I know that you are parodying the Agile mindset but any philosophical framework within which you make software has edges. We try to not make them count by having good hiring practices. I'll be the first to grant you that hiring is an unsolved problem in software development.
However, there are other considerations with TDD, probably on a more theoretical level that:
* There is no other major engineering branch that uses testing this way in production (would you bang a car against the guard rail to see if it works?)
* There is one thing common for sure with all of the bugs you catch in production, they all passed the unit tests
I think testing has it benefits but driving(!) your software development efforts is probably too much, at least for me.