Recently I had an interesting buzz conversation with a former work-mate, Peter. Just like myself he heavily orientates his learning to best practices, especially into agile software development methodologies and automated testing.I was doing a refactoring session, modifying a huge part of the core logic of my Android app which I'm currently writing as a part of my MSc thesis and after succeeding I published the following message on Twitter:
just #refactored application critical core logic. Would have been totally impossible without #unittest
I also do write unit tests, taking my unit out of its context, verifying its correctness in isolation. But hey, I never ever worried about whether I was writing "unit" tests or "TDD tests". Sure, some of my TDD tests are pure unit tests and others cover 2-3 units maybe, but I've always seen the unit testing framework as the tool and TDD the methodology. Do we need to be so strict about this difference? Would it change the way we write the tests during development??
Then there is regression testing. Nobody is perfect and so you always again run into sub-optimal situations during development. But do you have the courage to refactor and make it better? How will you be able to know you didn't break anything else? IMHO serious refactoring cannot be done without a substantial suite of automated tests (your regression testing suite) which has an acceptable code coverage.
TDD is so important because it will definitely improve your design ,  and more importantly it is a test-first approach. As mentioned, code coverage is important for being able to trust your tests. With a test-last approach, first you just won't be able to reach such a high code coverage as in a test-first scenario and secondly writing tests after will result in much more pain and effort.
 D.S. Janzen and H. Saiedian. Does Test-Driven Development Really Improve Software Design Quality? IEEE Software, 25(2):77–83, 2008.
 L. Crispin. Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software, 23(6):70–71, 2006.