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.