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.
Using a automated testing tool can help with that.