IMO, TDD shines when:
You're doing completely data oriented tests
You're doing things that have to work under changing (non-GUI) conditions without crashing
You're using embedded/system level controllers which need to be functioning under all inputs.
You have a moderately data intensive app and a moderately complex GUI action required to put in edge cases.
You have a automation framework at your disposal to push buttons and capture window contents.
You can structure your project into backend library/front end GUI using library.
TDD lacks luster when:
You have lots of GUIs and no automation framework
You have poor definition of system behavior (proofs of concept based apps sometimes have this)
You have an embedded target with limited debugger support
You have physical switches in your application
You have apps with lots of heterogeneously structured mutli-threading (the more conditionally compiled/run code, the worse the heisenbugs get), especially with a strong GUI component.
As you've implied, there are probably situations in which TDD is useful. There are situations where TDD is detrimental. The discussion I want to have is to define and support as precisely as possible when it's good to use TDD and when you should not. This isn't a call to bring up objections that I can shoot down - I'm genuinely interested in knowing because not knowing (or at least having a very good idea) is unprofessional (in my opinion, obviously).
Anyone who disagrees TDD is "a mixed bag" is unprofessional (as you pointed out - "No silver bullet!"). What I asserted originally was about what's in that bag. I asserted that not knowing is unprofessional because then you're advocating or dismissing a practice without evidence.