Eh, secp256r1 is fine. These days we even have complete formulas for it. secp256k1 is also fine, but in practice only ever used in somewhat legacy blockchain applications. (Recent ones tend to use pairing-friendly curves and more esoteric constructions on top.) Curve25519 is definitely a bad choice for anything but EdDSA and ECDH (and even there it's annoying) due to the cofactor, but ristretto255 reuses most of Curve25519's code and implements a prime-order group with a similar performance profile, so that's what I would pick if I needed a prime-order group in 2023.
Still, point is that there are pretty much two applications using secp256k1, who already have pretty good implementations for themselves, and the broader Go ecosystem doesn't get much from having us spend resources on maintaining secp256k1 alongside secp256r1 (which is definitely staying because of TLS and FIPS, amongst other reasons).
> I think I have more cryptographic domain experience than some random furry-avatar security blog writer.
Still, point is that there are pretty much two applications using secp256k1, who already have pretty good implementations for themselves, and the broader Go ecosystem doesn't get much from having us spend resources on maintaining secp256k1 alongside secp256r1 (which is definitely staying because of TLS and FIPS, amongst other reasons).
> I think I have more cryptographic domain experience than some random furry-avatar security blog writer.
oof