Why should I use User secrets only in the Development environment?

You can find it in the link you provided to the User Secrets documentation:

The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.

I think the short answer is that you probably could if you wanted to but that it is not what it is intended for.

My understanding is that the primary purpose of User Secrets is to keep credentials out of source control. In the days before GitHub and the cloud, most developers just stuck any and all credentials in the web.config and it was mostly ok. Then lots of people started using public repositories and AWS and all of a sudden https://www.zdnet.com/article/trufflehog-high-entropy-key-hunter-released-to-the-masses/

There are now a great many different tools out there for managing secrets, which one best suits your needs is a much harder question, but you could consider:

• Are you using access controlled source control?
• Are you cloud or on-prem for build and deploy?
• Who has read access to the live servers?
• How sensitive is the data you are storing?
• What other applications are running on the server?

I was just poking around in the CreateDefaultBuilder method and found this, which is perhaps relevant:

if (hostingEnvironment.IsDevelopment())
{
    Assembly assembly = Assembly.Load(new 
              AssemblyName(hostingEnvironment.ApplicationName));

    if (assembly != (Assembly) null)
          config.AddUserSecrets(assembly, true);
 }

Obviously you don't have to use the default version and you could add secrets for all the environments, but there it is.

This is a development time only tool. Storing any kind of secret in a file is risky, because you may accidentally check it in. In production, you can for example use environment variables to hold secrets (or any other more secure mechanism.)

While environment variables are one of the most used options in web development there are some reasons why this may not be the best approach:

1.The environment is implicitly available to the process and it's hard to track access. As a result, for example, you may face with situation when your error report will contain your secrets

2.The whole environment is passed down to child processes (if not explicitly filtered). So your secret keys are implicitly made available to any 3rd-party tools that may be used.

All this are one of the reasons why products like Vault become popular nowadays.

So, you may use environment variables, but be aware.

User secrets are basically a JSOn File somewhere in your user directory. That works well on your dev pc. But on a production system, the values should usually be injected through more production ready configuration system(s), like Environment Variables, appsettings.json or a azure keyvault. Envs and appsettings are already activated per default.