While I've never quite worked with anything as drastic as the "One True Script" described here, I have seen some pretty odd things, including a software company who's new client installation script for the database created the schema as it was several years ago then proceeded to apply every DDL statement written for the schema since then. Of course this meant it took hours to setup a relatively empty database for a new client.

Somewhere else as a DBA, I had a developer tell me he thought everything in the development database should be recreated from the scripts periodically. So when I asked if he was going to script all the test data that made up the development database to reapply after we reran the DDL and loaded the static/default data, he seemed to quickly drop his push to recreate everything from script. 😉

Where I'm at now, we have several different development databases, esentially one for each project, and then an extra one which is a straight copy of production database for working with current issues and bugs. So they can code at least semi-independently. There is only 1 QA database though, and I wouldn't want to change that. Production shouldn't be the place that interactions between different changes are first seen.