Even though I can sympathize with the tone of the OP, I think his argument cannot be generalized. Consider the following scenarios:
A one-person engineering team. This is some 20-something working on a start-up in his parents' garage or the 40-something code hobbyist out there that likes writing fun little apps every now and then. I would argue that there is virtually no need for testing unless you're either bad at writing code or inexperienced. I've written dozens of applications (in various languages) and once you get into the swing of things, you don't need TDD to actually "test." Debugging/edge cases/etc. just becomes a natural process of writing code.
A two-person engineering team. This is a secondary stage in every start-up -- sometimes, start-ups even are founded by two engineers. Here is where TDD starts being important. I may be an expert coder, but if my partner isn't that great (or if our code doesn't work well together), not testing can be a huge nightmare. But the impact is still relatively small. Bugs are easy to spot as both engineers are (or at least should be) incredibly familiar with the entire codebase.
Three-person to 10-person engineering team. Here is where things get really tricky and TDD becomes integral to meeting deadlines and actually, you know, putting out products. You've got Jim working on some financial stuff while Bob is optimizing some JPA code. At the same time, Susan is implementing a couple of new features. Having a test suite ensures that behavior will remain predictable given non-centralized iterations. Without TDD, large teams would be fixing bugs more than they would be writing code (most teams probably do that anyway -- not that it's a good thing).
10+ people; open source projects, etc. When you have more than 10 people working on a project, I think that TDD is simply a necessity. There are simply too many moving parts. Without a cohesive test suite, having this many people mess around with code will undoubtedly break stuff.
Ironically, I think that small teams put too much emphasis on TDD, whereas teams in larger companies (AT&T and IBM, for example) put too little.
A one-person engineering team. This is some 20-something working on a start-up in his parents' garage or the 40-something code hobbyist out there that likes writing fun little apps every now and then. I would argue that there is virtually no need for testing unless you're either bad at writing code or inexperienced. I've written dozens of applications (in various languages) and once you get into the swing of things, you don't need TDD to actually "test." Debugging/edge cases/etc. just becomes a natural process of writing code.
A two-person engineering team. This is a secondary stage in every start-up -- sometimes, start-ups even are founded by two engineers. Here is where TDD starts being important. I may be an expert coder, but if my partner isn't that great (or if our code doesn't work well together), not testing can be a huge nightmare. But the impact is still relatively small. Bugs are easy to spot as both engineers are (or at least should be) incredibly familiar with the entire codebase.
Three-person to 10-person engineering team. Here is where things get really tricky and TDD becomes integral to meeting deadlines and actually, you know, putting out products. You've got Jim working on some financial stuff while Bob is optimizing some JPA code. At the same time, Susan is implementing a couple of new features. Having a test suite ensures that behavior will remain predictable given non-centralized iterations. Without TDD, large teams would be fixing bugs more than they would be writing code (most teams probably do that anyway -- not that it's a good thing).
10+ people; open source projects, etc. When you have more than 10 people working on a project, I think that TDD is simply a necessity. There are simply too many moving parts. Without a cohesive test suite, having this many people mess around with code will undoubtedly break stuff.
Ironically, I think that small teams put too much emphasis on TDD, whereas teams in larger companies (AT&T and IBM, for example) put too little.