There's an interesting discussion going on about TDD: Tim Bray, Uncle Bob, Peter Seibel. I'm a fan of TDD, no big expert, but most of the code I'm proud to have written was test-driven. So here's my two cents.

Under-the-hood

That's where test-driven coding shines. Problems are well-defined and clearly bounded, you want to write simple APIs to keep things modular, so you have natural test points for the code. That's where the tricky refactoring happens too, because there's lots of external code using such a module, so it's not obvious what could break. Bugs have room to hide.

TDD helps separate the concerns of design and implementation: you design (think about what to build, write tests) and then implement (make those tests pass). You get regression tests basically for free, and you can add features incrementally.

Bodywork

There's also front-end work. You're not exposing a simple and clear API; rather, you're designing user interaction. You want to get all the little details right, keep the interface simple and intuitive and consistent.

TDD doesn't work so well here. For one thing, tests at this level are harder to write, so they take more time. Also, you can't separate design from implementation, because the design evolves as you experiment; in other words, the implementation is the design. There's not much external code depending on front-end code, so you're unlikely to break something inadvertently; any mistake you make is reflected immediately in the user interface. Still, some level of testing is useful, to make sure things don't break in obvious ways, e.g. checking that a rendered web page does contain the expected message somewhere in the HTML.

Use your judgement

TDD is a great tool, and like any tool, it can be over-used. Like Uncle Bob says, keep a small roll of duct tape around. But writing dependable library code without TDD, or at least very good test coverage, that's just asking for trouble.