I've looked at the new package configuration and deployment features in SQL 2012-2014, and while I wish they were there from the beginning I don't see anything that makes me want to give up on my SQL configuration. Granted some of my reservations may be due to limited use of the new project features and therefore not being completely familiar with them. I believe you can mix SQL configuration with project configuration, so you might do both. With project configuration you can mark things like passwords sensitive and they will be encrypted and hidden, although with some effort anyone with access to the project source code can get the plain text values.

Using project properties for configuration is great, but only applies to a single project. If you have multiple teams developing their own SSIS packages in their own projects, and if a configuration change needs to be made across all projects (say the name of the corporate mail server changes) then all those teams have to open all their projects, modify the property, and redeploy. If a package is deployed to multiple servers, then multiple redeployments. I just have to make a change to my config table in SQL and everyone's packages continue to work.

I also like that in my system the choice of production vs test vs dev happens automatically. The new project configuration scheme lets you define environment-based configuration values and deploy a specific configuration at will, which is a great improvement over juggling multiple XML config files. But I worry that someone will at one point deploy the wrong version somewhere through inattention or negligence, and how would you check on that afterwards?

One of these days we will finish our Windows Server 2003 and SQL 2005 migrations (lots of technical debt around here), I can finally install and play with SQL 2014, and maybe get seduced by the new configuration features. But so far I haven't seen any reason to.