There could be some value to that. My thinking is that the declaration that there should be only one argument passed is kinda like a keep off the grass sign, but then the compiler is throwing a warning that the keep off the grass sign is actually on the grass. The consumers of this should have a warning, but since we are handling legacy behavior (of passing two arguments) there should be no warning inside of this function. When things change, ie, if we remove the optional argument, then we would immediately know if we forgot to change things because then this would be an error, as the argument mismatch was very obvious.
I certainly agree that blindly suppressing all warnings is not a good call. I'm investigating the way that the compiler works, as I'm very new to this. My thinking is that we may have local definitions of byte-compile-enable-warnings that include (not callargs) *only* when compiling a function that contains a (declare (advertised-calling-convention (newArgs) "version")). This would make sure that others that hit this would be warned about the api shift but allow "bad" calls to it to still work. Then, when the optional argument is finally removed, if someone forgot to remove the old call, again, inside of the original defun, it would be a compiler error and not warning. But presumably, if you are changing the function signature like this you would be responsible for the entire body of the function.
Again, this is a proposal only for this specific type of warning, and not just suppressing warnings inside of the core. I want warnings to be informative and a cause of action, not to be ignored. This warning is superfluous and should be removed. If the best case is just a (with-no-warnings ...) so be it, but I think there is a more clever solution here, and one that actually fits the nature of what is being done with a advertised-calling-convention change.