I think the truth exists somewhere in the middle. I did a coding dojo with a brilliant manager a few years back on TDD, and learned a lot about the value of unit tests.
The first advantage is that it gives you a usable API (API is UX). It's all too easy to get tunnel vision and write an unusable API because you've never attempted to use it. The "doesn't compile" step in TDD makes sure that you are trying to use the thing before making the thing.
The other advantage is that it prevents you from solving problems that don't exist. The specific example we had was roman numerals. At the start of the session I felt a bit of dread: roman numerals are, superficially, pretty hard to parse. Working through "I" to "III" to "MCVIII" resulted in a complete solution that was far simpler than the one I conjured up before we started coding.
But, you'd never get anything done if you followed TDD strictly.
I think the middle ground is writing your code while visualizing the test. This ensures that you are writing units (which are easier to use and obviously easier to unit test).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.