You would only care if you're trying to deploy to lots of different environments. If I have to get the same database to two, three, five, different environments, but, there are different settings, security is the one example I use because it's the most common problem we run into, required for each of those environments, you need a mechanism to tell the database to deploy differently AND the same in each environment. The "same" part of that deployment is the core database project. This project will need to have connection strings to each of the various environments. In prior versions of Data Dude, I used command line batches with variable settings to be able to deploy one project to multiple locations. With the configuration, I get two things, the ability to change the connection string AND the ability to store it with the project, in source control, so that more than one DBA can grab the project and repeatedly and reliably deploy it.

I think so. If the only deployment you care about is on a single machine, yeah, you sure don't need this hassle. But when you have to deploy this to Dev, QA, CI, Financtial Testing, Training, Performance Testing, Staging and Production, the other QA enviroment because we're working of a branched version of the code right now, the sandbox server, etc., ... You might want a mechanism for maintaining which set of security is in use in which environment and a way to store that information with the project.