But it didn't. And there were other bits of language like that, including ones for which it's less clear-cut (and even some code checked printf), and then the question becomes where do you draw the line in the defaults.
So the idea was to pass every compiler and linter. Whenever a warning appeared -- such as due to code changes, moving to a new platform, updating some library, etc., -- that was something to look at, not to assume you knew the warning was innocuous and get in the habit of disabling warnings.
The environment is a bit different now, with everyone using a small number of standards-compliant and featureful compilers. When you had situations like, e.g., your cpp on one new platform not even being quite K&R compliant, and potentially mangling your layers of macro expansion subtly, you really needed every hint you could get that something wasn't parsing or behaving like it looked like it would.
It was also perhaps faster just to do all your pedantic practices, than to try and reason about when you needed to do them.
Today, of course, especially if I'm using only one compiler, I might not bother with void on printf. That's where I might redraw the line, like you suggested. (Speaking of personal code for which I have stylistic discretion; for other code, I'd defer to the current conventions of the project and/or discuss with team.)
Though, a side benefit to being conspicuously pedantic is that, when you see a chunk of code that is less-pedantic in some way, it stands out. When we have so many critical defects due to insufficiently perfect C coding, spotting a chunk of code (especially one's own code) that's a little less-pedantic might mean that someone who worked on that was maybe being a little cavalier at the time, and maybe that chunk is a place to focus some attention.
Being warnings&lint-free isn't the most important thing in C, and my bigger concern is that, as a practice, overall, we don't agonize enough over C code correctness and manageability.