The answer is no - a professional developer should always use BDD.
No seriously. I read this today and didn't hesitate a second to steal the topic since I there are two discussions around TDD I love; the discussion with people who struggle to write good code and the discussion with people who write really good code. I guess this is more about the latter. When I get into a discussion with the great developer it is often claimed that they think about testability when they write the code but then never find the time to actually write the tests. Yet there is always something in the code that could have been better if some tests were actually written; a few bugs that would probably have been found with tests or a design that is hard to test.
So the next argument is that writing the tests slows this great developer down. Well I would never do something that slowed my team down. Even if one person can write code that is so good it is not worth the time to write tests if that person is the only one ever working on the code - I would agree that it is a bad idea to write those tests since it is a waste of time. The problem is that you do not know when that is the case. And you need to consider the full lifetime of the code (which is typically much longer than you expected) and the time of the team to work on the code. Time to first release is typically not what is interesting but what most people think about.
So far I've been ranting about writing tests, not TDD, so what is the deal with TDD? Well I couldn't agree more with the conclusion from the fishbowl referenced in link above; a professional developer should not always use TDD but I would expect them to have tried it, mastered it and use it when appropriately. To me, that's a no-brainer.
I think you have misinterpreted the comments of the panelists in this fishbowl. No-one was arguing that they don't have time to write tests. Everyone there was clear they do write tests, and lots of them. The argument revolved around whether you should use the classic TDD process to produce the tests.
@Emily; Good clarification because I did no misinterpret the comments from the fishbowl. I just started ranting about discussions I've had which your post from the fishbowl reminded me of. So yes my post is covering a lot of things that has nothing to do withy the fishbowl discussion I referenced to and I should have been more clear on that.
You're absolutely right. Nobody knows who would be the next one to join the team or to work on the code. And you know I don't believe in perfect developers... mistakes happen to everyone and it's quite a good method to catch them while writing tests not while the app is in PROD :).
For me a TDD is more about writting a testable code and at the same time writing the tests. I'm not a big fan of the idea first write a test then change your code ... well to be honest it seems to work only in few scenarios... well designed and not crappy tests are something that lets me sleep well ... or at least better. If you see that the daily commit is building and passes all tests on continuous integration server one can be a little bit more happy about the solution :)