A clean build looks like this
CC foo.o
CC bar.o
CC parser.o
parser.c:42: warning: new thing found here (-Wnew-thing).
CC lexer.o
...
you hide all the details of the compiler command line so the diagnostics stand out.Warnings-as-errors is just a kind of negotiating hammer that is useful in team situations, when the developers have gotten used to ignoring new warnings, usually because they are hidden among reams of ignored old warnings.
Also, in a compiler that has a GCC-like interface, you can turn specific warnings into errors, which is useful. If there is something you don't tolerate in the code base, and it happens to be diagnosable as a warning, then you can error it.
GCC turns some required ISO diagnostics into mere warnings, like say assignments between incompatible pointer types. That kind of thing may be worth turning into an error.
The solution was to introduce a deprecation message that wasn't technically a warning, and warn about the upcoming depreciation warning.
Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.
Sometimes the package maintainers who make binaries for themselves and others don't want to fix bugs. At most some minor build things, but something actually broken is punted upstream.
You may see behaviors like the program being disabled (unavailable) for some platforms because it couldn't build or tests didn't pass. Or the package will stay on the old version of the program: 1.2.3 isn't building, so we just give up for now and stick with packaging 1.2.1. Maybe 1.2.4 will fix it. In these situations, package maintainers will not always contact upstream; the developer doesn't know unless they go into that distro's site and search the issues for activity related to their program.