Consider the following CI procedure is in place:
- Builds are only deployed (semi-)automatically.
- All changes are version-controlled.
- Configuration is fixed per environment.
Why use data files (*.config in .NET) versus code for configuration?
Yes, it would technically be "hard-coded" although still centralized rather than being scattered (normal best practices still apply). The benefit is that you would get more of compile-time verification. Maybe some unit tests as well.
Possible reasons against:
(Advanced) users may be allowed to change some configuration manually (e.g. detailed graphics settings in x86 games).
It might be useful to see what is the configuration without going to source repository when the application is crashing on start?
Is there a difference between 'connection string' type of settings vs 'inversion of control container config' type of settings?