For me, the first point above is the most important: TDD improves interfaces and design.

I agree with this.

What I find disconcerting is that many when they hear TDD and dismiss it never get around to writing proper tests at all. To me, that's an absolute shame (s/ (shame)/insert_bad_word $1/). Not following TDD != don't write any tests.

For example, I know of a company with a very large software suite, and it pisses me off to no end that bugs are frequently found that should have easily been caught if even a few basic tests had of been written. I mean, you have a feature in your software for many years then suddenly it breaks when one is doing a deployment? Give me a break.

I do TDD most of the time, but not all of the time. That doesn't mean one shouldn't write tests at all... it just means its much more unlikely that anyone will get around to it going forward. Personally, 100% coverage is my objective, from several different angles. Either specific existing tests (possibly having been updated or added to) are run before a commit, or if required the whole suite passes first.

Whether one does TDD or not, never neglect a good quality test suite. It doesn't matter if the project is late. On a complex project, would you rather have data inconsistencies in client data down the road because of your neglect, or have the project behind a couple weeks up front because you're validating your code before or as you write it?

update: This kind of sounded like I'm reflecting on you, eyepopslikeamosquito, but it surely wasn't. It's a global thing ;)