My experience is primarily in scientific software which has more string<->number conversions than the norm, so others' mileage may vary, but I can confirm that

My experience is primarily in scientific software which has more string<->number conversions than the norm, so others' mileage may vary, but I can confirm that a lot of widely used C and C++ programs are significantly slowed down by their use of standard library I/O functions. Often written by domain experts with more than a decade of experience, not noobs. Yes, once a particular programmer knows about the problem, they can solve it pretty quickly by switching to faster and narrower functions. But this is happening one programmer at a time. Practically everyone is still learning the wrong default, and switching away only after they've noticed they've been burned by it, and scientific programmers at least are being burned by enough other things that there's no guarantee that they'll ever notice this detail, even if they're generally very competent. (We're initially trained to not worry much about this sort of constant factor, after all.) The lowest-hanging fruit I see is in the compiler enhancement domain. They already e.g. inspect printf-family format strings, redirect the containing function call to fputs/memcpy when the string contains no format placeholders, and when there are format placeholders a warning is printed when the number of additional arguments does not match the number of format placeholders. If we could count on snprintf(buf, bufsize, "count: %d", k) being compiled down to little more than a 7- or 8-byte memcpy followed by a call to a dedicated integer-to-string function, I think the associated gain would be far more than "0.01%".