Hi,
2 reasons.
1. The project was started back in the .NET 1 era when there was no separate section for connection strings
2. appSettings section has the advantage where a default value can be in web.config and then you can override it from a separate file as we do in user.config. This makes things much easier for developers who are working from the source code repository because we don't have to modify web.config to add our connection string, we use user.config which is not under source control.
<connectionStrings section can be put in a separate file but it is an either or thing, that is if we point the section to an external file then the file must exist or an error will happen so the separate file would also have to be in source control and would have to be modified by each developer to point to their local database.
Whereas settings in <appSettings file="user.config">
can still have a settings with the default value in web.config and no error happens if user.config file does not exist, but if it does exist and the setting is there is will be used instead of the one in Web.config. So in source control the user.config file does not exist and developers can add one with no conflicts.
This also helps for upgrades because we do not ship a user.config file in our package, therefore during upgrades the connection string in user.config is never lost and there is less maintenance of custom settings.
So when the <connectionStrings section was introduced in .NET 2.0 we did not see any compelling advantage to change to use it and we continued to use <appSettings because it has advantages not provided by the <connectionString section..
Hope that helps,
Joe