Isn't that one simply that BDD is about testing the functionality independent of how it is implemented, making BDD good for acceptance tests. And TDD is more about testing parts of an implementation to see that it does the right thing to implement the functionality, making TDD good for keeping on the path while implementing.
But yeah. Terminology within testing is quite messy. Some things are overlapping, different groups have different names for the same thing, and different groups have the same name but for different things.
Maybe this is the issue -- I've seen these things explained the other way around.
My experience is in Ruby (specifically Rails), with Test::Unit (usually used to espouse TDD), and RSpec (recommended for BDD-style development).
With TDD, I follow the pattern of using real objects for almost everything (only mocking out API wrappers, etc.), setting some initial values, poking a method, and then testing that some final values are as they should be.
With BDD, I end up mocking and stubbing almost everything, and then writing a test that checks that my object under test calls the right methods on other objects.
I like the BDD school for its focus on testing one class in isolation, but often when writing BDD-style tests I just end up echoing the (eventual) implementation in test-form, line by line. It's entirely possible I've got utterly the wrong end of the stick, but I can't shake the feeling that it seems a bit redundant at best, and of little added value at worst.
I'll have to read it again a few times more so I don't miss out on any good conclusions.