There are legitimate use cases: for instance, a multi-tenant app that designates tenant by subdomain.
Every time someone adds a domain to Tumblr, they'd have to re-do the certbot challenges for all 50 MILLION domains.
Plus, all 50 million domains are listed IN the certificate. It'd be megabytes worth of additional data for every visitor to Tumblr.
*.tumblr.com makes a lot more sense.
Generate a cert for 100 of your client's domains, use that cert across those domains. Cut your 50m domains down to 500,000 certificates. Serving the right certificate for the right domain is a simple enough task.
As new tumblr domains are registered, generate more certs in batches of 100 domains.
I doubt anyone would ever seriously suggest putting millions of SANs on a single certificate, but 100 isn't too farfetched.
My situation is a bit different: hosting a bunch of subs on the same servers.
With one wildcard I have one server conf with one cert and use the hostname to rewrite each request to the correct directory.
If I did a cert for each sub the nginx conf would need 1000's of server config blocks each with its own cert. I haven't tested, so maybe nginx would handle this just fine, but it is easier to just go with a single wildcard and not worry about it.
As far as I can tell there is no security advantage to having multiple certs instead of one wildcard since I would have all the certs on the same server anyway but if anyone knows of any I would be happy to hear.