I appreciate that this is a bit confusing, especially in light of the fact that the meaning of what BDD is has evolved over the years since its introduction. At this point, and I think this is made clear in the book, BDD has evolved to a methodology that includes TDD as a practice. We still use the language of BDD to approach TDD from a different angle, but the process is exactly the same: red/green/refactor, small steps, etc.
In regards to enough up-front thinking, there are a series of scopes to which it applies. When you’re in a release planning meeting you want to do enough up-front thinking to be able to start working on the release with confidence. This will likely include considerations like business strategy, marketplace, etc.
In an iteration planning meeting, the scope is narrower. The goal is still to do enough up-front thinking to start working on the iteration with confidence, but the considerations tend to more about the functional details of specific features that we’ve already selected in the release planning meeting. Perhaps you don’t do separate iteration and release planning meetings, and that’s fine, as long as you recognize that even in the context of a single meeting, the concerns for release planning are wider than the concerns of iteration planning.
Within an iteration the scope is narrower yet. You still want to do enough up front thinking, and perhaps you’ve recognized some design challenges that are presented by the features slated for the current iteration. In that case you call a design meeting with your peers. The goal here is stay within the scope of what you’re doing this iteration.
Then, when you get down to the minute to minute practice of doing TDD, the scope is even narrower. The focus is on objects and how they respond to events in given contexts.
At each level, we’re informed by what we know from the wider scopes, and we can’t help but consider the things we know. We’re human, after all. The trick is to avoid the temptation of considering the things we don’t know or are not relevant to the task at hand.
I once heard Mike Cohn describe the idea of a planning horizon. I think it’s described in his book Agile Estimating and Planning as well. The premise is that when we’re planning anything at all, the closer we are to taking specific actions, the more detail we need to consider. The inverse is true as well: the further out the actions are, the less detail we need to consider. When we’re sitting down to write code, we have a lot more detail in mind than when we’re considering introducing a new project.