C.S. Degree in 1996, 20 years "professional" programmer and I never once thought TDD was helping my project. Every time I did it, it was because the boss told me I had to. Litmus test: every side project I did just for me, I never did TDD.
When reading Uncle Bob and others I have always got the feeling that the "goal" of the practices described is to have systems that can be maintained and extended for years by different people and teams. It never crossed my mind that Uncle Bob would recommend TDD for that tic-tac-toe I wrote to learn Buzzscript.
How many projects at all end up that big?
How many of those end up falling under their own weight?
How many of those failures are attributable to lack of TDD?
How many of the succeeding ones succeeded on account of TDD? Or in spite of TDD?
All I've seen so far is anecdotal evidence, which is no evidence at all.
The lessons by Raymond are also given in the context of OSS. Unfortunately it would be extremely difficult to find a team of developers that are passionate about the kind of stuff that SAP is written to solve, for example.
The lessons of Robert Martin and others are about how to be a professional developer. When you are writing software for someone else to use and they pay you money to do it, it is your reaponsibility to think about quality, extensibility and maintainability. It is not your job to express your self.
My take is that the point of TDD being so rigid is that a professional should always follow best practices, not just when they feel like it or when it is easy or convenient to do so. But TDD is an ideal and sometimes, or maybe even most of the time, there are externalities that make you fall short of that ideal.
When George Lucas was given unlimited time and money, he produced inferior films.
McCartney and Lennon's solo efforts don't stand up to their collaborative works.
Elvis eventually became fat, gaudy Elvis.