I am not sure I agree with it being worse. Would you rather have code with no tests or code with tests even if they do verify what it is doing? Most regression tests are brittle because they never change and get hardened. In my previous life, I was majorly behind model-based testing which is very similar to concepts of TDD in that it forces people to think of your entire component and then it generates tests or can walk through your reference implementation to verify your actual code. However in smaller companies, I personally feel that it is important to first test the right "it" before building it right. (As Google Engineering Director Alberto Savoia used to put it).

No one is advocating releasing broken stuff, but whats the point of releasing something perfectly tested that no one wants? I think the answer lies somewhere in the continuum. And in my own startup (wello) we do go back and write tests, because testing everything manually does hurt once the feature is working well and users actually want what you are building. So we do carve out time and write tests and often times then build it right. You could argue that this is inefficient, but I could also argue that for many features we removed because users did not want them, we saved the time needed in upfront TDD.