You are correct. BDD does not eliminate problems with language ambiguity - not at all. As others pointed out, the snippets that get translated need to be matched by properly defining them, but this also does not address the underlying ambiguity problem.
Now why is BDD actually worthwhile despite not solving this problem? There are some reasons and this list certainly isn't complete.
Ambiguity has not been solved
This is neither a reason in favor of BDD nor against it. But when you contrast it to other approaches like user stories or requirements, then all SW development approaches suffer from language ambiguity as they all start in one way or another with a natural language formulation.
Technically, the problem of language ambiguity has been solved with artifical languages like lojban, but then again, your customer and developers will most likely not know that language.
Ubiquitous language
BDD goes hand in hand with the idea of an ubiquitous language. Being able to specify scenarios together with all customers, testers and developers, just gives BDD an edge over other approaches.
Consider a traditional requirements engineer writing down all the requirements. Once you as a tester or customer get that 300 page document full of requirements to review you will have a lot more pressing problems than the terminology that was used there.
User stories do a little better on that front, since they also include all stakeholders in their creation. In terms of the ubiquitous language, I wouldn't say that either BDD or user stories are better - though they do differ in the next point significantly.
Testability
A major aspect of BDD is that your specifications are actually executable (via Cucumber or the like). Neither requirements nor user stories offer this feature. For me personally, that's the main selling point for BDD.
Contrast that with traditional requirements - we have been telling requirements engineers for ages that their requirements should be testable. Yet, every project sees a case where somewhere down the line testers realize that they have no idea how to test a certain requirement.
User stories, if done right, include testers in their early creation stage to make sure of that. Unfortunately, this is a case of theory clashing with the real world, where I have seen numerous stories that no tester has seen before.
BDD on the other hand automatically gives you an executable test scenario. There are no excuses and no ways around that (well unless you completely ignore the automation layers and just write down scenarios for the fancy poetry).
More generally, Test First is a principle that has been very rewarding across all stages of software development and BDD is its application to the outermost layer of the development (as compared to f.ex. TDD on the unit level).
Summary
In summary, BDD does not eleviate you from the problems of natural language ambiguity. It does, however, help you to tackle that problem via two important points: Focusing on an ubiquitous language in order to reduce the ambiguities (it won't eliminate them entirely, but it helps a ton!) and by forcing you to write executable specifications. The latter point is helping to address ambiguity problems mostly because that is the point where ambiguities start to show up as problems otherwise.
