I've heard of TDD as an organizational development paradigm, where all developers are asked to let testing drive development, and I've also heard of organizations who don't embrace TDD so long as unit test coverage reaches close to 90 percent for the application. One thing I never hear is why an organization would set a standard for TDD specifically when it is an individual development discipline.
The main benefit of using TDD instead of building your tests afterward is that the system tends to be more "clean", and by that I mean less coupling, responsibilities where they belong and a clear public API. Testing after the facts tend to produce tests designed to pass, jumping to the hoops that the system imposed (like having to connect to the database because the DAO is coupled with the database code).
All in all, I tend to mix approaches: Most of the time I TDD, some times I just code (specially when I'm experimenting) and use tests afterward to clean my mess.
Here's what I think you are getting at. Take a team/organization that is well entrenched in TDD. They hire a new programmer who is very good, but no experience with TDD and in fact, isn't convinced it really works (They hired this person to provide diversity and potential new ways of thinking.).
As long as the new person writes good code that meets the specifications and happens to fit in with the entire project without testing first, who cares? It's not the process but the product. I think it does matter. You don't code on an island. Eventually someone else is going to have to work with this code.
It doesn't matter if it is following formating standards, naming conventions, TDD, Scrum, OOP or EIEIO all members should work within the framework of the team. It doesn't make them a bad programmer; just a bad fit. Not all teams are perfect nor are all methodologies, but unless you can change everyone else, you need to get on board at least for the current project.