Working on large and complex application becomes near impossible without extensive unit test coverage.
If you're using unit test of all things to guide the design of your application, you are off the deep end. That makes you a bad programmer, it doesn't make TDD bad.
Part of the problem in discussions like these is that people aren't really clear whether they're complaining about testing or TDD in particular, whether they're arguing about the benefits of TDD specifically, unit testing, or testing in general, and everybody involved may read the wrong thing into any ambiguity.
I, for one, would not argue with unit testing (particularly for libraries) or regression testing, but I think that an insistence on TDD can be excessive.
That's a good point, I often catch myself conflating TDD with general unit testing.
I definitely ascribe to TDBF (Test-Driven Bug Fixing) more than TDD - if a bug shows up in my production code, adding a test to the suite to make sure that bug never comes back gives me a great deal of peace of mind. And it helps if I have enough of a testing framework from initial development (such as data and mock object setup) to add new tests quickly. But I definitely don't do enough testing for it to qualify as TDD.
Oh, yes, absolutely. I think few people would argue with that, though they may not have formally articulated it as "having a test framework". (To my understanding, what you're referring to as "TDBF" is more commonly called "regression testing".)
As is often the case, most arguments are about extreme positions.
If you're using unit test of all things to guide the design of your application, you are off the deep end. That makes you a bad programmer, it doesn't make TDD bad.