The quote is a very specific answer to a very specific question:
If you use the Certbot client (formerly known as “Let’s Encrypt”), and if you tell it update Apache or Nginx’s configuration, it will disable a number of insecure and obsolete cryptography and protocol settings, making the website incompatible with certain old clients, including IE 6 on Windows XP, which is archaic and insecure.
If you do those things, and choose to be compatible with those clients, you would have to spend 1 minute making further adjustments to the web server configuration.
When you choose to have Certbot adjust the web server configuration, it uses the “Intermediate compatibility” settings from Mozilla’s configuration guide. You would have to change it to the “Old backward compatibility” settings, or another similar configuration.
https://wiki.mozilla.org/Security/Server_Side_TLS
Mainly, you would want or need to enable a few insecure settings.
Since the browser doesn’t support SNI, you would also have to make sure the IP address’s default – or only – certificate includes all necessary names. (Fortunately, Let’s Encrypt makes that easy!)
My understanding is that third-party browsers, like Chrome and Firefox, have more modern TLS implementations than Internet Explorer 6, and can probably connect to websites using a normal configuration. They remain insecure and obsolete, though. (Edit: On Windows XP.)
Edit:
I forgot to answer your second question.
If the browser only supports Insecure Options A, B and C, and the web server only enables Secure Options X, Y and Z, the user would usually receive a vague error page about ‘protocol errors’ or ‘cipher overlap’ problems, and they would be unable to do anything about it, except upgrading to a secure browser.
If the web server requires SNI, but otherwise has everything insecure enabled, the user would probably receive a normal ‘domain name doesn’t match’ error page, which they can probably override.