I think they want to use something more like an environment contextual config fetcher instead.

For example:

test.appsettings.json

{"db-url":"test.url.here"}

prod.appsettings.json

{"db-url":"prod.url.here"}

Now in the code:

Settings.fetch("db-url");

// Will return the test one if environment variable says we are running under test environment, else will return the prod one.

The DI-based configuration system can be configured to do exactly that. Though yes, the configuration is maybe harder than it should be simply because it isn't on by default.

A lot of the complexity in the configuration system exists to enable a lot of configuration options. I have some ASP.NET applications that get some configuration from Environment Variables on the host machine, some from environment-specific config files, some from a configuration service (specifically Azure Key Vault), all without any of my DI-injected downstream components specifically needing to know which source provided specifically which configuration key. For the DI injected things it is just `config["db-url"]` or maybe type-safe class if I DI-inject an IOptions<T> (or add my type-safe classes directly to the DI without the IOptions<T> wrapper, which is another configurable option).

It's absolutely a very complex system, but with great complexity comes great flexibility (to badly paraphrase the Spider-Man mantra).