By coincidence I've also encountered this same surprise today! 😀

How I understand this problem:

When using an SSH tunnel to forward a local TCP port to a remote TCP port, the remote TCP port might be addressed using a hostname that the server can resolve but the client cannot. This arises, for example, when the tunnel is being used as a bridge into a private network that isn't otherwise connected to the internet, and that remote network has its own internal DNS.

Resolving this client-side means that the address in the remote network must either be specified directly as an IP address or the private IP address must be exposed as a publicly-resolvable hostname (which is atypical in my experience, to avoid disclosing unnecessary information about the remote network).

I think this proposal suggests that when the n argument is tcp/tcp4/tcp6 (or one of its variants), to send the addr string directly to the server rather than first resolving it to an IP address locally and then stringifying that IP address.

That makes sense to me in principle, but directly sending the address string to the server (without attempting to parse it locally first) would mean that addr here gets interpreted in the way that the SSH protocol requires, rather than in the way Go's net package would interpret it. I don't think those interpretations match exactly, but I'm not sure if the differences actually matter.

(In particular, I notice that the specification text in the screenshot says "Some strings used for 'address to bind' have special-case semantics", and I would guess those special cases are not echoed in package net's address parser.)

When using an SSH tunnel to forward a local TCP port to a remote TCP port

IMHO, for local port forwarding, resolving the listen address on the local side is correct, but for remote port forwarding, resolving on the local side of the address that will be listened on the remote side is strange.
I am faced with the problem of access from golang to the public jumphost.

text in the screenshot says "Some strings used for 'address to bind' have special-case semantics"

Please look RFC. It's about aliases like 0.0.0.0, localhost, 127.0.0.1, [::1], etc
By the way by RFC sending localhost should lead to binding on remote side both tcp4 127.0.0.1 and tcp6 [::1],
but resolving localhost on local side lead to binding on remote side only tcp4 127.0.0.1 \8^(

Duplicate of #37239

That is, it is impossible to create a client on golang that would work like OpenSSH!