my two cents

Here are some points to consider:

a) TDD for assuring the quality of APIs usually has a good ROI. However, using it for creating systems is not always a good idea (I think it is better applying the 80-20 rule).

b) This article is probably talking about TDD for unit level tests, but no considering TDD for functional tests. For systems, functional level tests (e.g. user interface tests) probably have a better ROI. So TDD at the functional level can be less painful.

c) There are many good tools that can automatically generate useful tests, and give us a good ROI. Capture-and-replay tools are not always a good idea (Selenium IDE, FitNesse, etc.), but tools such as FunTester (http://funtester.org) or TaRGeT () can be very useful for testing systems.

Some additional comments:

@1 and 2:
Testing, not just TDD, is an expensive practice. I agree that TDD can delay the project launch. However, depending on the business area, we need to assure a certain level of quality, and plan the releases according to this reality. In this case, TDD can help us to discover quality problems early.
TDD also requires a certain level of maturity and understanding about the environment and the business area of the software. Not well trained developers tend to apply it wrong. (Tip: For those who wants to start with TDD with the right practices, I strongly recommend to read the book "Growing Object-Oriented Software Guided by Tests").

@3 and 4:
That's why I think we need to apply the 80-20 rule and focus on complex or error prone things that will give us the best ROI.

@5:
Using a automated testing tool can help with that.

--

Right, testing is always an investment in quality, but doing TDD for every component in your project is just crazy, you are never done with it. Time passes and business that do not deliver fail.

You certainly can reduce some costs of testing with existing tools but the costs of testing everything upfront remain significant.

As I said before, we need to focus on what give us the better ROI, not on the entire project.

We don't need to test everything upfront, but incrementally, as the project evolves.

I think that whether we follow these simple practices, TDD can work without problems.