The scope of this article is to demonstrate how to implement a custom provider, using a database was an example.

Still, I disagree with your premise. Just like we can say the appsettings.json file must be present and is required to start the application, the same can be said for settings loaded from a database or external API. In the implementation I made, the startup will actually fail if the database is not available - not on purpose, just for example simplicity.

Having an external source for Options, like a database, is a valid approach since you may want to have different configurations per environment that can be easily changed by the DevOps teams, without having your application to code specific scenarios - everything will come as an options class.

Using an appsettings.json file or environment variables may not be an easy to govern approach. As an example, Microsoft offers the Azure App Configuration service to manage all application configurations in a single place. There are other providers that try to solve the same problem. If your application is implemented without abstracting this, a change in provider will imply changing all applications.