I would generalize this slightly to something like:

This advice can also apply more generally to other formatting situations
when a dynamic string could confuse or change the formatting or meaning of
surrounding text when interpolated.

Mostly to avoid bucketing "logging" as "formatting" (i.e., structured logging - which is at least as relevant as log.Printf scenarios - doesn't require the same treatment for fields, because they are already discrete values).

I think the log.Printf example is fine to keep, I would just put a good/bad example under the fmt.Errorf examples.

Whenever formatting messages that contain a string component via fmt, use %q instead of %s.

I think we might want to clarify slightly: it's not necessarily just when a string component in general is used, but more when dynamic strings (incl. user-provided values) could potentially cause interpolation to result in something weird.

Maybe something like:

Whenever dynamic strings - such as user-provided data - are used for formatting,
prefer the placeholder %q over %s.

[...] helping it stand out from the rest of the error message.

More importantly, if the string is empty, it will provide a more helpful error message.

I'd either generalize these slightly or remove the word "error" (this guidance can apply to more than just errors). Maybe something like:

More importantly, if the string is empty or has its own formatting, the result
will be clearer and more consistent.