This seems like a special purpose operation. When does it come up in practice?

When allocating a bunch of small strings when the total size of all strings in more or less known.
This is currently kind of possible using the current API, but not really convenient to use.

func main() {
	var b strings.Builder
	// Case 1: Size known upfront.
	// The size must be known upfront, so that it doesn't grow
	// anymore, because it will unecessary reallocate the previous strings
	// in the builder.
	b.Grow(len("test1") + len("test2"))
	str1 := newStringSizeKnown(&b, []byte("test1"))
	str2 := newStringSizeKnown(&b, []byte("test2"))
	fmt.Println(str1, str2) // test1 test2

	b.Reset()

	// Case 1: Size not known upfront.
	b.Grow(len("test1"))
	str1 = newString(&b, []byte("test1"))
	str2 = newString(&b, []byte("test2"))
	fmt.Println(str1, str2) // test1 test2
}

func newStringSizeKnown(b *strings.Builder, buf []byte) string {
	l := b.Len()
	b.Write(buf)
	return b.String()[l:]
}

func newString(b *strings.Builder, buf []byte) string {
	if b.Cap()-b.Len() < len(buf) {
		b.Reset()
	}
	return newStringSizeKnown(b, buf)
}

Can you explain what this is trying to achieve? What problem does calling .Reset() cause that this fixes?

Can you explain what this is trying to achieve?

Just performance optimizations, reduce a bunch of small string allocations into one bigger memory allocation.

What problem does calling .Reset() cause that this fixes?

With the .Reset() it is currently possible to simulate the .ResetKeepCapacity() method, but the .ResetKeepCapacity() is just simpler and it does not require workarounds as in the examples above (#60768 (comment)).

You could keep track of your offsets, call the String method once, and slice the resulting string.