Compatibility, inertia. Who wants to be the first CA to break compatibility with some obscure SSL library from 2005? There's little downside to the status quo.
Of course, this becomes less of an issue over time. Systems are replaced or upgraded, and unrelated changes (e.g. banning SHA-1) reduce compatibility with obsolete software anyway.
Buggy software is a different issue. Who wants to bet that there's at least one current, semi-prominent library that has bugs with CN-less certificates?
I'd guess that the compatibility issues are near-zero today -- barring unlikely but possible bugs -- but i don't have a lot of evidence.
Normally? No. If you generate a custom CSR and use the --csr option? Maybe.
You'll have to wait for someone else to chime in. The Let's Encrypt CA software supports it, but it's configurable. They might have it off.
Yeah, you're right. I was thinking that, say, if you had ten names, you'd probably be happy to issue a few certificates with three or four names each. Issuing fewer certificates is probably less of a hassle for you typing certbot commands, if nothing else. And there's no branding issue if, say, example.com, www.example.com and static.example.com are the same certificate.
Most of the rate limits are per-domain. Rate Limits - Let's Encrypt If the way you want to split things naturally aligns with that, they're not an issue. (Issuing one certificate for example.com and example.net, or issuing two certificates, one for each domain name, has the same rate limiting cost.)