The term "BDD" was coined by some TDD practitioners to solve a specific problem: when teaching TDD, the most important hurdle to overcome, is to understand that TDD is not about testing.
Dan North realized that one problem with understanding that TDD is not about testing, is that everything screams "TEST" at you: you are using a test framework to write test cases by inheriting from a class named TestCase and writing test methods whose name starts with test. You use testing terminology everywhere: "assertion", for example. So he thought: what if we simply remove all the words that are about testing and replace them with words related to behavior specification via examples? It's still exactly the same thing, except without the misleading words!
And that's exactly what a BDD tool is: it's the same as a TDD tool, but without the testing terminology. That's how Dan North wrote JBehave, for example. If you already understand TDD, and understand that TDD is not about testing, then it doesn't matter what tool you use. But I, personally, find it easier to get into the mindset that I'm not writing tests, when I'm, well, not writing tests but rather examples. So, for me, BDD tools are easier to use, when I use TDD tools, I am constantly battling with myself "I know this is called a test, but it isn't one, it's an example, you stupid brain!"
This is even more pronounced if you show your tests to someone else, e.g. a non-technical stakeholder. You could either explain to them that while this looks like a test, it isn't really a test but rather an example of the behavior … or you could use a framework that makes it look like an example of the behavior. The Great Dream™ that non-technical stakeholders would write executable specifications has not come to pass, but I know of several organizations where the non-technical stakeholders routinely read, and sometimes even edit Gherkin examples, even if they are not writing them from scratch. Obie Fernandez once wrote a web-based structural editor for Cucumber (which probably doesn't work anymore) that would let non-technical users edit Cucumber Scenarios in a structured manner, and immediately execute them against the codebase, and his non-technical customers actually did use this editor to write new scenarios, and communicate their wishes in the form of executable examples.
tl;dr: TDD is not about testing, BDD is TDD without the testing terminology, BDD tools are testing tools without the testing terminology. If you can manage the mental divorce from testing while using testing terminology, it doesn't matter what you use. However, be aware that you may not be the only client of those "tests", even if you are the only one writing them, you may not be the only one reading them.