Whether to put web.config in source control or not?

What are we missing?

A proper secret management.

Production secrets don't belong to source code, nor configuration. Developer machines should not have production secrets stored on them. Essentially, if a developer machine is compromised, the hacker should not be able to immediately gain access to your production by reading a bunch of files.

Developers could, potentially, access production (although I would rather advise not to), by logging in to production machines (also a bad sign, usually) with their Active Directory account, and only then see the actual secrets. If this does make sense in a given project (for instance if developers also have ops roles, or if the application has no security requirements).

Since you talk about Web.config, I suppose you're using .NET. The approach specific to .NET is documented in Safe storage of app secrets in development in ASP.NET Core article and consists of using:

dotnet user-secrets set "Movies:ServiceApiKey" "12345"

to create a secret, and:

var movieApiKey = builder.Configuration["Movies:ServiceApiKey"];

to access it.

Last but not least: whenever you can, avoid secrets whatsoever—a secret that doesn't exist is a secret that can never be leaked. Examples:

• A password to a technical account that is used by everyone to access a given machine should be replaced by proper Active Directory integration.
• A password in a connection string to SQL Server database should be replaced by Trusted_Connection=True.
• A password used by a service to access another service should be replaced by a TLS client certificate, managed not as a secret, but through the operating system as any other certificate.

Do. Check in web.config. Set it up for running locally on dev machines.

Dont. Tell your developers production secrets. If they don't know them they cant check them in.

Do. Have your deployment pipeline inject secrets or identities when the app is deployed. In such a way that no-one can see what they are

The essential question is "Where do you store your production passwords/identities/deployment accounts etc?"

Even if you use identities you can't avoid having passwords and auth for the admin account you use to setup those identities. But ideally this is stored on a piece of paper in a locked cupboard with 2FA enabled.

If possible, set up your deployments so that the identities are on the box/cluster/pods by default so that even the deployment doesn't need to know them

If you still need a password, put it on a secret management system and give the deployment account the right to retrieve it and write it to web.config or an env variable, user-secrets etc