The idea is that you'll understand the problem space better by writing the test first. Which is IMO a valid assumption. But, at least for me, the problem space (interfaces etc.) is often a bit too fuzzy initially, such that it's easier to just write the first draft, and THEN test that.
Maybe it's one of those things where you have to get over the hump. But to me it's much more enjoyable to write what I think is the perfect function and then try to break it with my tests.
I also don't understand how anyone could think that a strong typesystem is a replacement for tests. It definitely helps one write a lot fewer tests for the same level of quality, but you still need tests.
Usually I write out a set of tests (this should this X, Y and Z but not H, I, J) and then I implement whatever thing I need to add.
Same with bug fixes or changes. Bug fix: reproduce in tests, then fix bug. Change: change or create new tests, then update code.
This suggests that you don't understand that people can achieve the stated goal of "a comprehensive suite of tests" without TDD.
Just to be clear, people can be passionate about testing without being passionate about TDD.