A couple of points that I'd like to clarify:
I too understand that the database configuration string must live SOMEWHERE outside the database. I also understand the reasoning that it was put in one of the Sitefinity-specific configuration files for the sake of consistency. That said, the problem this causes is that we no longer have the option of using the built-in Microsoft config transformation functionality to swap out build environment-specific (production, staging, dev, etc.) connection strings. Thankfully we can use pre-build events like this solution detailed by Scott Hanselman
to achieve a similar result, albeit with a good deal of additional hassle.
Also, I need to reiterate that when we make a configuration change through the Sitefinity admin interface in our production environment, the Sitefinity config files in production are updated. The way things stand at present if we do not then take the MANUAL step of copying those files back into our source control system, the next time we deploy our code to production (this happens FREQUENTLY with us as we develop new server and user controls for use in our Sitefinity environment) THOSE SETTINGS WILL BE LOST!. I fail to see how this makes ANY sense and I truly do struggle to believe that you have not received this feedback from MANY other customers (or perhaps they just haven't worked with v.4 long enough to notice this yet). As Thomas said, the ONLY setting that really can't be stored in the database is the database connection string itself, and my hope is that Telerik (specifically the Sitefinity Team) will give some consideration to making this a high priority upgrade. I really do like Sitefinity and I am very impressed with most of the changes that have been made in v.4 (except for the fact that I can't use Shared Content Items in Page Templates, but that's another rant) and I would probably still recommend it to my developer friends but I would do so with some reservation and would certainly note this issue as a big drawback.