One problem is the updates in toolchains that come up with new warnings, a lot of which are nuisances. Developers get tired of the make-work which that generates, either to fix the warnings or else identify where they are coming from and put in options to stop them.

The real problem are warnings that are super-useful (find a bug) about one out of twenty times (or less). The other nineteen times, they are false positives, such that refactoring the program to eliminate them is a fool's errand.

You don't want to turn off these warnings, and you don't want to fix all instances. So then you need per-file warning disabling, or start using compiler-specific #pragma-s:

   #pragma GCC diagnostic warning "-Wno-whatever"

The issue is incremental compilation. It is common (although not universal) that the way the build system (interpreted broadly) remembers that there are errors in unit X is that it has failed to produce a (new enough) unit X. In that setting, -Werror turns warnings from something that might not be surfaced in a (re)build into something that will be.

In my experience the warnings tend to pile up. Once you have a few warnings in the codebase, what's a few more?

I think a good compromise is warnings aren't allowed in the final committed code (this can be enforced either by convention or with git hooks), but whatever you do locally is between you and your compiler. "What happens in the devbox stays in the devbox"

I'd tend to agree, though this can be harder to set up than just having a consistent build config for all platforms.

Generally I would hope that your CI build allows you to set this kind of configuration. (At the very least, you must have this as an option, because someone will run into it at some point and will have to turn your -Werror off.)

In large bodies of code, you might not notice the warnings if they weren't errors.

Code size can have something to do with it, but less than you think.

Basically, you don't notice warnings because you choose not to look.

Firstly, no matter how large the program is, if it builds without warnings and then a change is introduced which triggers a warning, it will be noticed. You only don't notice a new, potentially important warning when it is drowned out by "nuisance" warnings that you stopped caring about months or years ago. This tends to be a problem in larger programs worked on by many people, but it could easily affect a small, solo-effort program as well.

You perhaps don't notice warnings because the build log is too long to read, and you haven't put in CI process which scans logs for warnings and produces feedback. When you build locally, you don't bother using an IDE which picks up all the errors and warnings out of the build output an lets you navigate through them. This can be a problem when people don't build locally; they just throw the code into some remote build system and if it goes "green", they "ship it".

This is generally why such a policy is often accompanied with "we don't want you introducing warnings; the policy is just relaxed while you're developing the code".