I agree with the eggs/basket argument, though I suppose there's an argument to be made about a number of CAs being essentially too big to fail already, so what's one more?
Regarding client certificates: There aren't really many good reasons to use publicly-trusted certificates for client authentication, but if you insist, you can use Let's Encrypt for that. The certificates do have the id-kp-ClientAuth EKU.
I think it would be nice to move toward having a lot of medium-sized nonprofit CAs instead of a handful of crappy commercial ones, which is the current situation.
"Too big to fail" is the problem with the current CA system, and today's well-run TBTFCA is tomorrow's global security crisis.
OMG yes on wildcard certs! My company has multiple domains and uses subdomains for every affiliate and we have thousands of affiliates. One *.example.com cert per domain and we're good to go. Now if only we could get IIS to support multi-domain wildcard certs so we could get all of our domains and subdomains under one master cert I'd be in heaven! (SNI doesn't work for us b/c ~12% of our traffic still uses IE7 or earlier).
So why not buy one now? I get the excitement about simple certification process, free access and refresh, etc. But if you have thousands of affiliates, current wildcard cert providers should offer a pretty good solution. Is anything missing there? I mean, if we ignore the idea why LE is good in general, $100 / year is nothing if you actually need a wildcard.
Oh we absolutely do just buy them now through RapidSSL. It's all of those other reasons I wish LE supported them. I wouldn't mind paying LE for them, I want an API for requesting them, a simpler certification process, and easier refreshes.
I don't get the desire for longer-life certs. I would argue that they should be shorter to keep the exposure of a leaked cert down. Whether a cert is good for a week or a year you should be automating the renewal.
I don't think 'competitor' is the right word here -- maybe 'second basket so all our eggs aren't in one'.