TDD - Testes são somente a consequência

Pois é, você pode até ter ouvido isso em outro lugar, mas existe uma grande chance de você ter "descoberto" antes mesmo de ouvir.

Sei que é óbvio, mas como vejo muita gente confundindo o "processo" de TDD com Testes Unitários, resolvi dar minha contribuição.

O TDD tem como objetivo dirigir o design da implementação, essa é, sem dúvida, o maior lucro de usar TDD. O segundo maior lucro é ter sua aplicação coberta por testes.

Tendo suas implementações dirigidas por testes, estes se tornam parte da sua aplicação, pra ser mais claro, o código desenvolvido na classe de teste passa a funcionar "até mesmo" como documentação, além do óbvio, que é o fato da sua implementação ter sido baseada no teste. Um método pode, em muitas situações, ter sua implementação modificada pra facilitar o teste.

Por que a confusão(TDD X Testes Unitários) acontece?

Simples, porque fazer TDD é fazer Teste Unitário. Porém, você pode fazer o teste unitário após a funcionalidade estar concluída e isso não é TDD, você terá seu código 100% coberto, mas como já falei, o beneficio maior é dirigir a implementação, ter seu código 100% coberto é apenas a consequência de fazer TDD.