There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.
Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?
You have it backward. This is installing a red light in the middle of a road where there is no intersection because 10 years from now there is a plan to build a crossroad and then wondering why people are angry about a traffic jam in the middle of nowhere. People who ignore warnings are the people who run new red lights and will eventually kill someone when the intersection goes in. The people who upgrade them to errors stop at red lights, don't kill anyone, and get rightfully pissed that someone put a red light up 10 years too early.
The people who upgrade warnings to errors are those who wire the check engine light to the brake. This is fine for a test environment where you want to highlight problems, but it does not mean you get to yell at whoever improved the check engine logic to detect more potential problems if you car now stops in the middle of the highway.