While I know this post has already filled it's intended purpose, I have a few thoughts to add to it, as I find the general conversation to be interesting.
I have built pages based on databases, XML files, flat files, and automatic generation of static pages. Databases are not always the best solution, even if they can be the fastest to implement (if thats where your experience lies). However, while having a single good solution to a problem allows you to turn out a site quickly, there are places for other solutions in your toolset as well.
For instance, a few sites ago I wrote a site administration from scratch that used a template file (HTML), a data file (text), and a content generation script to output static HTML files. The purpose of this was to reduce the load time, process utilization, and necessary maintenance of a page to the absolute minimum. The owner would go into the administration tool, make his changes, and the press a save button. The data would be placed in the data file (so that it could be pulled back out for editing later) and then a page was generated from the data file and the template page creating a new static page that overwrote the old version.
The net effect was that the owner saw a little higher processing time (maybe) then if I had simply stored the data in the database, but the site required no database and had a slightly faster load time and higher simultaneous user capability. This means a lot less maintenance for myself, less load on the server, and no worries about tuning the database when traffic grew.
Would this solution be good for all needs? No. In fact he had a section of his site that was fed by a database. I tend to only use databases when there is dynamic content involved. Treating the whole site as dynamic content requires that much more code in the visitor pages. By moving the work of applying occasional verbiage change to the administration tool, it kept the pages simpler and made the processing occur once per change rather than once per visitor per page.
As far as time to develop is concerned, this comes down to experience. It takes me slightly longer to write a PHP page then it does to write an ASP 3.0 page, but that doesn't mean PHP has no place in my toolset. Overall ASP.Net doesn't speed up my development a great deal, but again, there is a place for that in my toolset as well. Just as there are places for different languages or technologies, there are places for different design or implementation methodologies as well. Sometimes it is worth the time to use an opportunity such as this one to explore a new methodology.
