Thanks for the clarification. Being able to disable cipher suites in TLS <= 1.2 takes care of a lot of my concerns. It does still remain a concern for 1.3.

I still do worry about the lack of ability to disable cipher suites. Does that extend to not being able to say "I will only accept certificates signed with RSA?" Because if you are forced to allow EC certificates then there are a couple points in the past where this could have been an issue ( https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ ). Furthermore if we imagine a future where an issue is found with how one of the ciphersuites is implemented (say ChaCha20 is done incorrectly and we only want to allow AES-GCM) then being able to disable the known bad ciphersuite is a great band-aid.

Let's say that you are providing a Go application to a customer. The customer can configure the application with a config file that controls TLS params. If you can configure the TLS ciphersuites and an issue is found the customer turns off the ciphersuite until they can upgrade. The alternative is that you go through a chain of: vendor gets new Golang -> rebuilds application -> does in-house testing to make sure nothing else came in the new Golang that broke stuff -> customer gets new application -> customer does their own in-house testing -> finally it gets deployed. It's a way longer cycle if you rely on upstream to push changes in code.