Think that's part of it - a substantial amount of the web is on shared hosting (and probably dictated by other areas of the business) and as such wont have any level of root access. Therefore the hosting company can control cert installation and thus cost.
Usually add-ons are administered by the hosting company though (?) - so if they want to own the cert purchase/installation flow, then they can certainly do that.
If you have a shell and public I address, you can get a certificate. Root access is only required for Http authentication, you can also authenticate to LE using DNS. I actually just learned about the DNA ability.
Check out Lego project, it makes DNS Auth very easy :)
These hosting companies are already doing enough things "wrong" that if "well, everybody just stop using them" were going to be a viable strategy it would have worked by now for those other things.
We currently do not have the power to change the behavior or the market share of these hosting companies in any significant way. That leaves working around their behavior as the option.
Who said anything about doing it to change their behaviour? Do it because you aren't getting value for money! If there are better alternatives, then use them.
Not if you have user-generated subdomains, or have subdomains that you don't want to advertise in subjectAltName, or simply just want the full power you used to have with HTTP to use any subdomain you want -- then you'll need a wildcard certificate, which Let's Encrypt won't offer you. Nor will any other free CA, except for CAcert, which browsers will not trust.
The absolute cheapest I've found one of those for is $95 a year. So basically, more than all of my server hosting, my domain hosting, and my domain privacy combined, all to sign my CSR that has a one-character change in it.
Of course, if you want both yourdomain.com and www.yourdomain.com (because just *.yourdomain.com won't match the former), then that will, of course, cost extra. A lot extra.
I've heard it's possible, but it would be a substantially increased maintenance burden. You won't be able to put all your subdomains into the subjectAltName section of one certificate, and so you'll need to constantly reload your nginx/Apache configurations to reference all of the different certificates. Plus Let's Encrypt certificates expire every 90 days, and you will have to update all of your certificates before that happens.
I really can't for the life of me understand why they won't offer a wildcard certificate, if you prove you are the owner of the base domain name. The cynic in me expects it's the same reason every CA in existence charges four to ten times more for a wildcard certificate that literally costs them nothing more to make. That entire market would vanish overnight if Let's Encrypt offered them for free. I would even immediately start using them for my site.
I suspect it's both a policy question and the fact that there's not really much of a consensus on wildcard validation in ACME (i.e. how to approach it, and whether it should be a topic for ACME or just a policy decision for the CA).
In terms of policy, wildcards encourage some users to both reuse the same certificate for multiple services (i.e. mail, website, api, etc.), and use certificates that are "broader" than needed (use wildcards everywhere because they're "easier", despite the fact that you only need a certificate for imap.example.com). This increases the impact of Heartbleed-like vulnerabilities significantly (in that unrelated services using the same key are suddenly all vulnerable to MitM attacks). It might not be the worst idea to give the ecosystem some time to get used to non-wildcard certificates in order to discourage that behaviour.
I think there's a good chance we'll see wildcard support sooner or later.
I would welcome key usage constraints to limit a wildcard cert to https only.
But yeah I do hope you're right. I'll switch my domain off self-signing the moment a trusted CA offers a free wildcard cert with elliptic curve signing.