"A lot of upfront work would seem to be contrary to the basic tenet of speed and efficiency of the agile methods."

I would vehemently suggest caution when positing this. This is precisely where blind adherence to process falls flat, and using your brain reigns supreme. One man's upfront work may seem like "a lot", and another's insufficient. One man's speed to deliver while eschewing upfront work may be at the expense of quality of design of another's approach. On the surface, the basic premise is largely correct because we probably intrinsically "know what is meant" when applied to overly formalized, old-school processes.

However, it would be better, if we all agree to say it as follows:

Too much wasted upfront work... is contrary to agile methods.

Subtle, yes. But a nonetheless key "edit" to the statement up top.

This merely reminds me that it is a major challenge to ascribe absolute units of measure to "a lot of upfront work" and it's correlation to "speed and efficiency." While it is generally easy to provide such adjectives about the project after it is done or well underway, it is much more challenging to be predictive about some techniques before they are employed.

How to persuade folks that "Big Design Up Front" is wasteful? One way is to point out that your upfront effort should seek to maximize Return on Effort.

Effort	Return
Too little	With too little effort, you miss key discoveries that can materially affect design decisions. Discovering these critical drivers later in the project can cause excess scrap and rework. A quick start might give a sense of progress, but a late-statge discovery of a major requirement can throw your exisitng efforts out the window. You just wasted a lot of time and effort in the name of just getting started fast. A little planning will do you good!
Just right	You should strive to uncover the critical drivers to help shape the design. You should also uncover enough about the requirements to ensure you have no major risky unknowns lurking about. Here you will optimize your efforts. Gaining just enough requirements to properly shape the architecture and get started. Yielding visible results quickly and built on a foundation that will carry you into the future.
Too much	While it seems possible (and to some desireable) to gather all the requirements up front, this is an impossibility. As the system becomes usable, folks will think up new requirements, or change their ideas for existing requirements. So, it is a waste of time and very naive to try to do all of the requirements up front. This approach will yield a false sense of "completeness" of planning. Made worse over time as you soon discover that some of the upfront work was useless, some of it was downright incorrect, and much of it could have been done "just in time." In addition, you may have to revisit much of the early work anyway, as ideas may have changed, and certainly the developers will need to have the details closer to the time when they are designing and coding.

As your BDUF proponents want to explore more requirements, you can always ask yourselves if the details of said requirement is critical to uncover now. Or, can learning more about said requirement later on in the project suffice? By way of analogy, think about designing an automobile. Critical requirements that will drive major design decisions have to do with top speed, max acceleration, number of passengers, cargo space. These requirements will yield key architectural decisions about chassis, engine, drivetrain, suspension components, body shape. Non-critical requirements are more like interior treatments, seats, radio, nav systems, knobs, dials, instrument cluster.

Instead of BDUF, think "Just in time." You need enough upfront work just in time to be able to proceed with architecture and release planning. You need more details about the features in module X just in time for planning to have the team tackle those requirements.

Instead of depth, think breadth first, then depth. Quickly discover the breadth of the requirements. Quickly uncover the non-functional requirements that can dramatically shape the architecture approach. Only go into details of a requirement if it seems like it will be important to uncover sooner rather than later. Otherwise, merely jot it down, or add it to an object model. You can come back to it later when it comes up for scheduling in an iteration.

Were we able to do this as an industry, indeed an engineering profession we might one day turn out to be!