In my opinion, yes it has. In fact, I don't think that BDD is all that new of a concept. If you think of what Waterfall is, it is a development process that is business driven. I will try to answer your questions the best way I can.
1) I will let you research that. That might be a bit subjective and too lengthy to get into.
2) All types of testing should be covered as part of your SDLC; starting with the most neglected of all: Unit-level testing. I like to use pyramid to illustrate the amount of testing that needs to be done. At the lowest of levels (code) you should have way more tests than at the next higher level (integration), and so on. Your UAT and other E2E should be way less. For starters, it costs more to develop, maintain those tests, and to run. It is also harder to debug a system by running E2E. Trust me, I have been down that road many times and it is not pretty. In fact, if you feel you need to cut corners, don't do it a the unit level, do it a the top.
3) Yes. If you are developing software, you need to make sure your tests traces back to the contract. If you developing software for the entire world to use, with more of a reason you need well constructed use cases that you can use to derive your tests from. Otherwise, how can you be sure that what you're building satisfies the needs or your users?
4) Advisor? Code Police? I have been in teams where QA is totally neglected and not asked to be involved in development. The result is almost always the same: bad decisions that makes it harder for QA to test. Then QAs are ask to deliver under stress with almost impossible deadlines.Think about this, user-friendliness and performance are almost always in conflict with each other, but are both important. Likewise, QA serves as a balance to DEV. While developers focus on how to implement something, QA counters with how to make that testable. Compromises need to made early on, and QAs are not involved, only one side will be considered.