GitHub, for instance, has three million users. Provisioning a cert for each github.io domain would take 29 years. Yes, you can contact LE and ask for a limit increase, but three million certs would still spam the public cert transparency logs, LE's internal records, etc. significantly. That is a cost. LE rounds down the cost of an individual cert, even 20 certs per week, to zero, but the cost of three million certs is very nonzero.
2. Wildcards work in mass-hosting situations where individual certs don't. Again, for my college computer club's server, putting a few thousand <VirtualHost> blocks in Apache's configuration makes it take forever to start. I tried this. It was a bad plan. The better plan is mass-hosting tools like mod_vhost_ldap or even RewriteRules based on the hostname, but they don't let you interact with SNI, because as far as Apache (and thus mod_ssl) see, it's just a single <VirtualHost>.
3. In order to issue a cert, you need to publicly respond for the name on the cert. If you're issuing public-CA certs for private-network websites (which is generally a best practice over running an enterprise CA), you need to briefly configure a DNS entry for the private name to respond to either the DNS challenge or the HTTP challenge. You can't just configure a DNS entry internally. So your internal deployment process now involves updating public DNS. For anyone who's not running publicly-facing infrastructure (i.e., most companies, whose public Internet presence is just a website), there may not even be an automated means of updating public DNS.
A wildcard cert, meanwhile, will just email the owner of the registered domain via e.g. WHOIS contact info, which requires no external configuration, and is a one-time setup process. Everything else is internal at that point.
I love Let's Encrypt, but it's ill-suited to use cases where wildcards are popular.