The current usage doesn't seem like a big problem in practice. Can you point to code examples that would clearly benefit from this approach?

If we do this, then I don't think we should use unsafe.Pointer. We should use any.

The main benefit is that the function literal does not escape to heap. An example of code is in net/sendfile_linux.go:

var werr error
err = sc.Read(func(fd uintptr) bool {
	written, werr = poll.SendFile(&c.pfd, int(fd), remain)
	return true
})
if err == nil {
	err = werr
}

Here, in the function literal, 4 outer variables causes the function to escape: written, werr, &c.pfd, and remain.
If written, &c.pfd, and remain are combined into a struct and passed into f, and werr is returned directly, then this function literal won't escape:

// for demonstration only. in bigger programs, argType may be part of the containing type
type argType {
	written *int64
	pfd     *poll.FD
	remain  int64
}

// for demonstration only. in bigger programs, arg may be a parameter of the containing type
arg := &argType{&written, &c.pfd, remain}

err = sc.ReadWith(func(fd uintptr, arg unsafe.Pointer) (bool, error) {
	a := (*argType)(arg)
	*a.written, werr := poll.SendFile(a.pfd, int(fd), a.remain)
	return true, werr
}, unsafe.Pointer(arg))

Yes, in practice, this is not a big problem, but if we need to eliminate the unnecessary memory allocation caused by the escape of the function literal, at least this provides a way, so is meaningful. With previous APIs, we can't eliminate the memory allocation, as long as we refer something outside of the function literal, it always escape.

For the type of arg, any should be a better option to unsafe.Pointer.

I wonder why escape analysis isn't good enough here?

I have no idea. The calling path is sendFile -> Read -> RawRead:

func sendFile(c *netFD, r io.Reader) (written int64, err error, handled bool) {
	var remain int64 = 1 << 62 // by default, copy until EOF

	lr, ok := r.(*io.LimitedReader)
	if ok {
		remain, r = lr.N, lr.R
		if remain <= 0 {
			return 0, nil, true
		}
	}
	f, ok := r.(*os.File)
	if !ok {
		return 0, nil, false
	}

	sc, err := f.SyscallConn()
	if err != nil {
		return 0, nil, false
	}

	var werr error
	err = sc.Read(func(fd uintptr) bool {
		written, werr = poll.SendFile(&c.pfd, int(fd), remain)
		return true
	})
	if err == nil {
		err = werr
	}

	if lr != nil {
		lr.N = remain - written
	}
	return written, wrapSyscallError("sendfile", err), written > 0
}

func (c *rawConn) Read(f func(uintptr) bool) error {
	if err := c.file.checkValid("SyscallConn.Read"); err != nil {
		return err
	}
	err := c.file.pfd.RawRead(f)
	runtime.KeepAlive(c.file)
	return err
}

// RawRead invokes the user-defined function f for a read operation.
func (fd *FD) RawRead(f func(uintptr) bool) error {
	if err := fd.readLock(); err != nil {
		return err
	}
	defer fd.readUnlock()
	if err := fd.pd.prepareRead(fd.isFile); err != nil {
		return err
	}
	for {
		if f(uintptr(fd.Sysfd)) {
			return nil
		}
		if err := fd.pd.waitRead(fd.isFile); err != nil {
			return err
		}
	}
}

Pprof shows these 3 lines cause memory allocation, all of which are in function sendFile:

func sendFile(c *netFD, r io.Reader) (written int64, err error, handled bool) {
var werr error
err = sc.Read(func(fd uintptr) bool {

These allocations cause noticeable performance reduction on benchmarking.
Of course, if the escape analysis is good enough in this situation, then we don't need to add more methods to RawConn.

If the problem is escape analysis, it sounds like we should fix that for the code snippets above.
The compiler knows the underlying type of the result of f.SyscallConn().
A smarter compiler is always better than new API.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Thanks! If a change to compiler is feasible in this case, it should be a better choice to solve this issue.

Filed #51334 for the compiler change. This seems like a likely decline.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

OK, I'll follow the compiler change, please close this issue.
Thanks!

No change in consensus, so declined.
— rsc for the proposal review group