We may have different understandings of "TDD", so I suggest tabooing the term. Can you address your argument above to the description that follows?

The process I know as TDD consists of specifyfing the actual values of a precondition and a postcondition, prior to writing the third (command) portion of a Hoare triple. The "rules" of this process are

• I am only allowed to write a Command (C) after writing its pre- and post-conditions (P+Q)
• I must observe a postcondition failure before writing C
• I must write the simplest, "wrongest" possible C that satisfies P+Q
• I must next write the simplest P+Q that shows a deficiency in my code
• my algorithm should arise as a sequence of such Cs satisfying P+Qs
• my application code (and ideally test code) should be well-factored at all times

If you follow this process strictly, you can't even begin writing a huge test harness. The process enforces interleaved writing of application code and test code. As I've argued elsewhere, it tends to counter confirmation bias in testing, and it produces a comprehensive suite of unit tests as a by-product. It encourages separation of concerns which is widely regarded as a cornerstone of appropriate design.

Empirically, my observations are that this process reliably results in higher developer productivity, by decreasing across the board the time between introducing a new defect and detecting that defect, which has a huge impact on the total time spent fixing defects. The exceptions to this rule are when developers are too unskilled to produce code that works by intention to start with, i.e. developers of the "tweak it until it seems to work" variety.