The fact is that TDD takes resources away from other things. In cases where you’re writing underlying libraries this is almost always a good tradeoff, in that the robustness of the back-end saves countless hours of debugging in the layers built on top of it. In web development, this does not apply.

The typical web development process works like this:

Gather requirements.
Have artists design the pages.
Convert to HTML and hook into back-office systems.
Refine the requirements.
Tweak the designs.
Get new artists.
etc.

In some sense this is like all other software development. But the important distinction here is that the cost of changes to web pages is very small compared with changes to shrink-wrapped or back-office software. With the web it is possible to have extremely short release cycles and frequent design changes. In fact, the general public has come to expect their web sites to be continually refined to make their experience more gratifying.

The problem with trying to apply TDD to this environment is that it reduces flexibility, and thus makes the web site seem more clunky and less tailored to people’s needs. This is certainly true on the ones I’ve been a part of, but it’s also pretty obvious when you come across it (anyone ever try QuickBooks Online?)