On the surface there appears to be a conflict between model driven and prototype driven approaches to data warehouse design. Prototypers eschew designs as being too theoretical and taking too long, designers are suspicious that prototypers don't have a big picture view.
Experienced data warehouse practitoners utilize both approaches. Modeling based on best practice design - look at the plethora of industry data models available from the likes of Teradata, IBM and Sybase - can save time and effort, but are not conducive to fruitful requirements discussions with business users.
The strength of data warehouse prototypes are that utilizing real data and providing real answers enables business users to see what is possible and to frame requirements and set priorities. The two techniques do work well together. We were recently engaged in a Teradata implementation. The logical data model provided the first target for development, and the user community was essentially the business analysts who would probe and question to ensure all the data that would be useful was extracted and modeled to answer as yet unknown requirements. Prototyping was used with the model area as the source. Prototypes could be built rapidly as the data was (mostly) in place, and business users were engaged as they were seeing their data in a way they were going to use it.
In the mid market we have seen experienced practitoners undertake prototyping without modeling, in the enterprise space we see modeling and prototyping as complementary.