If TDD is slowing a developer down because they don't know what the architecture is, it's a strong indicator that the plan isn't complete.
By the time TDD is being used, it should be as obvious what to do as unpacking a U-Haul truck full of boxes parked in front of an empty house with the door propped open.
<sarcasm>By the time TDD is being used, you should have already have known way ahead of time the house you were going to move to in the future and simply just had your amazon orders shipped to that address in the first place.
If you have to move your boxes at all, your design was clearly incomplete originally and you should not have started buying belongings until you knew the final house you were going to live in first.</sarcasm>
Real life is too messy for TDD 99% of the time I find. Unexpected things happen (e.g. you move house) that means you can't know everything ahead of time.
I believe, in good faith, that more often than one percent of the time, the existence of a good plan is what enables TDD to be the successful demonstration it claims to be.
The trust that we grow as practitioners of good software architecture is what enables us to have these talking points. I believe that we should feel enabled to discuss how to succeed, and less so how to fail.
Inverting the development process may be useful for some well understood domains, but certainly not a majority, let alone the amount TDD zealots proclaim.