I am pushing myself down the TDD path. I say pushing because it is definitely a hard row to hoe. I'm not used to the test-first paradigm. I am getting better, but the purpose of this post is to talk about some of the benefits I have reaped from TDD, and help myself (and hopefully others) to learn why test-first development can help you code and your design.
Stability
Obviously, if you are writing a failing test, writing code to pass the test, confirming this every step of the way and your code coverage is good, then your code will be more stable. That doesn't mean it will be elegant or take the best approach, but it passes your tests. If your tests are good, then your code will be more stable.
Accountability 
Writing the tests first allows you to see the desired end result as a list of tests that must pass. This allow you to account for completion of the project. When you boss asks, "how are things coming?", you can reply, "72% of the tests pass." No more replying with vague answers and trying not to commit to anything. It is also a good "Light at the End of the Tunnel" for you as a developer. You can plan your days as, "I'm gonna get 10 tests to pass today." and you can feel good if you get 14 to pass, and know that if you work an extra hour to get all 10 tests to pass, then you accomplished your goal.
Design Ability
Writing your tests first forces you to look at your code from the front. It's easy, as a developer, to look at your code from behind the bar. You know your ingredients and you know how to put them together. Sometimes coming out from behind the bar allows you to see the situation from the consumer's perspective, whether those consumers are end-users or other developers. It forces you to view your code in the way it will be used, rather than how to get it to do something. This will inevitably improve your design.
Separated Concerns
Good layered, encapsulated, modular code is the goal of any architect (or at least it should be), and Test-Driven Development, in come cases, forces you to separate concerns in order to test them separately. As soon as you start to delve into TDD, you;ll start to see discussions about mocking and dependencies. If I want to test a method in isolation, I have to force dependant objects that I am not currently testing to give back suitable results. Mocking helps me do this, but it also helps me to understand the boundaries of the encapsulation of my classes. What should my class know about that class? What shouldn't it know? This will generally force to to make good design decisions. If you are finding it very hard to test something without mocking up 5 different objects, you may need to rethink your design.
Conclusion
These are just my thoughts. I am still really new to TDD and have a lot to learn. If you see things that I have forgotten from this list (undoubtedly a lot of things), or you think that some of my assumptions or assertions (pun intended) here are incorrect, leave me a comment.
~L