It's true that in many cases these expressions could be simplified, but the benefits seem fairly marginal. Let's take them in turn:

1. fmt.Sprintf("%s", x) // x implements Stringer; write x.String() instead
   This transformation is not sound: you have to know the dynamic type of x; if it implements fmt.Formatter, then the behavior may differ from x.String().

2. fmt.Sprintf("%s", b) // b is []byte; write string(b) instead
   This one is a win for clarity and potentially a win for performance since it avoids escaping the byte slice (though most byte slices escape, I suspect).

3. fmt.Sprintf("%s", err) // err implement error; write err.Error() instead
   Not safe, for the same reason as case 1.

4. fmt.Errorf("%s", x) // x is a string or implements Stringer; write errors.New(x) instead
   If x is a string then errors.New is equivalent, but in Google Go readability reviews the style question has long been settled that we shouldn't correct fmt.Errorf to errors.New; it's just not worth the trouble. If x is a Stringer than errors.New cannot be used (without a call to String, but see case 1).

5. fmt.Sprintf("%s", y.Name) // y.Name is a string; write y.Name instead
   This one seems like a win for clarity and performance; the Sprintf call is completely redundant, and perhaps just a mistake.

I wonder how common cases 5 and 2 are. I suspect rare, compared to uses of %s within a larger format string.

Related Issues

• proposal: fmt: improve ergonomics of fmt.Print-like functions #57816 (closed)
• x/tools/go/analysis: warn on Printf(fmt) #37935 (closed)
• fmt.Printf("%p", x) does not work if x has a String method. #1024 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

This transformation is not sound: you have to know the dynamic type of x; if it implements fmt.Formatter, then the behavior may differ from x.String()

Could 1 and 4 be rewritten when x has a statically known type? (With errors we are rarely given a statically known type in these expressions, so there's nothing to be done for 3.) Or do we want to leave open the possibility that someone intends to later make their type implement Formatter?

I wonder how common cases 5 and 2 are. I suspect rare, compared to uses of %s within a larger format string.

I found a few dozen packages matching Printf("%s", "literal") or Printf("%s", "concatenated" + x).

There are also many hundreds of calls like Sprintf("%s", str), although many of these are members of some pattern alongside other calls. A contrived example

var (
  x = fmt.Sprintf("prefix-%s", a)
  y = fmt.Sprintf("prefix-%s-postfix", b)
  z = fmt.Sprintf("%s", c)
)

fmt.Sprintf("%s", x.GetXXXXXX()) is a somewhat common way to get the string value for a protobuf enum field.

fmt.Sprintf("%s", err) is also very common (and usually is meant to say err.Error(), I'm sure), but as you pointed out, this one can't be soundly rewritten.

Could 1 and 4 be rewritten when x has a statically known type? (With errors we are rarely given a statically known type in these expressions, so there's nothing to be done for 3.)

Yes, if you know the type the transformation is sound.

Or do we want to leave open the possibility that someone intends to later make their type implement Formatter?

I'm not worried about that.

I found a few dozen packages matching Printf("%s", "literal") or Printf("%s", "concatenated" + x).

Both of those are redundant with Print, but they're really not mistakes--perhaps the author is following a local style rule of "prefer Printf over Print{,ln}"--so they're out of scope for vet's printf checker. Ditto your other examples.

perhaps the author is following a local style rule of "prefer Printf over Print{,ln}"

That's a good call, something I hadn't considered. There is enough room for doubt in each of these cases that we should probably leave these calls alone.