Many organizations do indeed prefer "quick and dirty" solutions hoping to get the code out the door faster, rather than investing extra effort in more quality-focused practices. These organizations are often also reluctant to adopt more modern development practices in general if it changes the way they have always worked.
That said, it is hard to generalize. A large number of the clients I work with to implement BDD and related practices are large banks, insurances, or government services. They take a few months to get it right, and they don't do everything perfectly to begin with (as with any new practice), but the ones who persist have some great success stories to tell (see for example
http://www.scrum.com.au/2014/sessions-2014/#Rowan Bunning). I also know many people in smaller companies and startups who are keenly aware of the value of quality practices.
I don't think experienced practitioners see a dichotomy between BDD/TDD (and code quality in general) and speed: other than the initial investment in learning the new techniques and changing a team's habits, BDD practices tend to make you go faster, because (a) you focus on writing code that serves a known purpose, (b) you spend a *lot* less time debugging (closer to 90% than 40% in my experience) and, most importantly (c) you avoid implementing features that would end up not being needed after all, and focus only on the genuinely useful ones. The collaborative nature of BDD helps you not only concentrate on what features are the most important, but also on how to build them in the most efficient way (the devs are good at this) and making sure you haven't forgotten anything (testers are good at this).
The study referred to in chapter 10 needs a bit of context, as the numbers might be misconstrued. It was a study (from 2008) on TDD (not BDD) practices, done with university students or new developers who had no previous experience with TDD. In other words, they were learning TDD as they went. I think this would explain the additional time taken (40–
90% fewer defects, and 15–35% increase in the initial development time). Also, the 15-35% "increase in initial development time" didn't seem to integrate bug fixes. As Kent Beck once said (I think), it is much easier to write code if it doesn't have to work ;-). In my experience, an experienced TDD/BDD practitioner will typically take slightly less time to deliver a feature than a developer not using TDD, and that feature will be virtually bug-free.
Personally, even for my own personal projects, I practice a BDD-style of TDD at the coding level for almost all code because I find it allows me to get code out the door faster.