This is definitely something I'd call a Frequently-Asked-Question (and I've even proposed it as such), but I don't know if there's an industry-standard best answer for it.
A few thoughts:
- If you have fewer domains per certificate, then the the TLS handshake that transfers the certificate is marginally smaller. For most users I suspect this doesn't really matter, but if you're serving bazillions of hits per day then the bandwidth savings can add up.
- If you occasionally add or remove domain names you're hosting, it may be easier to get a separate certificate for each name, rather than needing to update your single certificate every time there's a change. On the other hand, having only one certificate to keep an eye on (ensure gets renewed, ensure it has all the names it should, etc.) might make management of things easier for you.
- Anybody who looks into the details of the certificate being served can see all the domains involved. For many cases, this is pretty irrelevant (as it's no surprise that
www.example.com,example.com, andexample.netmight have the same owner), but in other cases it might give information that, while it might not be private, might not be something you really want to advertise. Like, if you ownwidget-manufacturer.example, the fact that you also ownwidget-retailer.examplewhich competes with other retailers thatwidget-manufacturer.examplesells to might not be something you want to make extremely public. - If there's some sort of problem with a certificate (say, something like the 2020 Let's Encrypt CAA rechecking bug where they needed to revoke a lot of their certificates on relatively short notice), you might not want to put "all your eggs in one basket" where all your sites could be unavailable for a short time or need to have your only certificate replaced. (Or maybe you'd rather only deal with it once than needing to deal with it for a bunch of certificates?)
For myself, I combine up to a few really-closely related domains on one certificate, but have different certificates for different things. So I'd put together www.example.com together with example.com without thinking twice about it, and probably put together whatever-as-a-service.example with api.whatever-as-a-service.example and docs.whatever-as-a-service.example or the like, but then again maybe I wouldn't if the different hosts really had a completely separate infrastructure.
Really, like a lot of infrastructure decisions, I suspect it's mainly all just about what you find easiest to manage in the long run.