If you're thinking of Certbot, the trouble is that Certbot doesn't know how or to what extent your prior certificate configuration is intentional. Some people might deliberately use a mix of self-signed and CA-issued certificates, for example for internal or test domains vs. publicly-visible ones.
The self-signed or snake oil certificates are, I believe, typically created by the OS package that installs the web server (e.g. an Ubuntu package for Apache). However, we don't have a uniform standard way for this package to tell Certbot (or another client), or for Certbot (or another client) to tell this package, "this certificate is irrelevant/temporary, so feel free to replace it with a different one".
Although it's true that SNI is a sadly late addition to the TLS standard, almost all clients support it by now. (For the command-line openssl s_client, you have to specify -servername in order to tell it what to send.) So I don't think it's that bad that non-SNI connections may fail for this reason. They're also extremely hard to get right in an automated way, because different administrators may want or expect different behaviors in this case.