When you have an app service, it has a "configuration" tab, which allows you to define key-value pairs that are treated as environment variables by your application.
Azure also has "Azure App Configuration" which is sort of like a cloud app.config where you can define key-value pairs and app service applications can access them.
As far as I know the recommended best practice is to use Azure App Configuration over the App Service's "Configuration" tab for values/data that isn't tied to the environment.
Still, why bother with an additional service when the "Configuration" does exactly the same thing (except the "flags" feature). Just store your config values there and access them as env. variables. Yes, it might not be a best practice, but what are the downsides? Why shouldn't I do it?
Yes, I can centrally manage multiple applications' settings from the app config but IMHGDBO that isn't that much of a bonus unless I have a lot of applications.
You definitely don't need to use Azure App configurations if all you have is a simple .net core app or a SPA tied to a REST API, or a 3 tier architecture etc.
But when you modernize your app and start breaking down your backend REST API into a microservice architecture with many services (Ex : a product microservice, a customer microservice, an auth service etc...), then orchestrate them using Kubernetes, then it becomes beneficial if you can centrally do logging as well as app configurations since this keeps your app debugging and management simple. That's where Azure App Configurations come in handy. When you need to change a setting that is used across all micorservices, you just do one change when using Azure app config.
I've personally also found Azure app configurations come in handy if you are deploying mobile apps that need to read dynamic configurations from the cloud.
You can read more about when you should use Azure app configurations here : https://learn.microsoft.com/en-us/azure/azure-app-configuration/overview