Behaviors Become Defined
If everyone is on board with the process instead of a list of requirements, everyone gets a list of Behaviors which then define the requirements. As the process is used more, and discussions are had these behaviors become more thorough and the requirements become clearly defined from them.
Test cases are easier
When BDD frameworks are used correctly, test cases are easier for everyone. By seeing in a human readable format what the test case was doing when it failed, you can then be able to determine further actions and discovery processes to determine any other issues.
Software Development tends to have patterns of defects. If your BDD framework has historical data, it will allow you to follow these patterns. As an example, one of the common areas for issues that I have seen is with roles and permissions. Since I know this is a common area for issues instead of waiting for development to finish, getting the code into QA, finding issues with it and then sending back to Dev I am able to ensure that part of the BDD includes the roles and permissions up front, ensuring that my developers understand exactly what they are attempting to accomplish.
Think first, Code later
All *DD follows this basic principle. Writing code is a privilege, one that is earned by determining the problems you are going to face up front. While this doesn't result in perfect code, it does help to reduce mistakes and makes everyone's life better.