The Go 1 compatibility promise (https://golang.org/doc/go1compat) does have an exception for "new security issues that come to light", but this really doesn't seem like it's a new security issue, but rather closer to a defense in depth measure.
I think the correct Go-like way to handle this is to deprecate the entire 'crypto/tls' package and tell users to use the 'v2/crypto/tls' package, akin to how go modules work.
That new package could then not have the 'PreferServerCipherSuites' option at all, which would make it very clear when a user migrates that this change is occurring, and if they relied on it they must make an appropriate change to their code too.
Obviously, the entire world would have to shift over (since a 'v2/crypto/tls.Conn' would not be compatible with a 'crypto/tls.Conn', it's a struct not an interface), but that also seems fair. It's what the go team tells users to do in the case of module versioning, so it seems quite consistent.
I find it surprising there's no mention of backwards compatibility or the go1compat page in the CL or linked issues.