TDD is like object-oriented programming. Nobody can agree how precisely it should work in real world, but "you'll know it when you'll see it". And you're 50% likely to embrace it, and 50% likely to decide it's utter crap.
Why does that matter? It means that you're writing a user of your class before you write the class. That means that the interface of the class gets designed from the mindset of a user, not an implementor.
More: The interface gets designed by someone who wants to be able to test all the externally-visible behavior of the class. If you can't test it, you have to think about re-designing the class interface - often by breaking it up into smaller classes. I've seen this in practice; the net effect of this is better class design (plus thorough tests).
That said, I'm considerably stronger of a proponent of tests than I am of TDD. If you don't like the TDD approach, still write tests. Write lots of them. They'll often save you when you make subtle mistakes in your next set of changes. (Nothing like fixing a bug, running the tests, and getting informed of all the implications of your change that you forgot about.)
> That means that the interface of the class gets designed from the mindset of a user, not an implementor.
From my experience, something entirely different happens. The class gets designed from the mindset of a third party - the tester. Which is, I believe, a mindset different from the user. If all you're testing is the externally-visible behaviour, fine. You're pretty much treating the class like a library. But if you start injecting stuff into the class to test if some other dependent services got called properly, etc. - and especially if you start designing the interface around such testability, then I believe it'll lead to bad, unreadable code. In particular, I believe adding complexity to the class for the sole purpose of making it easier to test is a code stink.
TDD taken to the extreme prescribes that you should only ever write dumbest possible code that makes current tests pass. If you need more complicated behaviour, you first have to write tests for it. But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer, because test complexity rises in lockstep with production code complexity. I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing, which makes one ask where did they have the code that tested if tests themselves are implemented correctly?
So personally, while I like tests (particularly regression tests), I just can't make myself follow TDD.
> But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer...
I've done things a lot more complicated than a simple CRUD layer. TDD held up just fine.
> I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing...
Well, blindly following any methodology is likely to get you in trouble, one way or another. The problem is blindly following, not that they're following TDD.
That said, I did TDD, and now I don't. It worked well for me, I loved the kind of code that came out of it, and I still don't do it any more.