Worth mentioning https://cipherli.st/ too. But I think more warning about HSTS is needed, since misconfiguring HSTS will cause the domain to be inaccessible for long periods.
I don't want to disagree with you but I do. I most certainly agree that HTTPS must be everywhere and it's easier than ever before. Where I disagree comes with less experienced developers. I can write a quick PHP / Rails / Node / whatever web server to show some website real fast, deploy by uploading it to a shared hosting package or something fancier like elastic beanstalk, and it's done and up there. Yes it's on HTTP but it's so easy. Now you want to add HTTPS to it? It's not easy. Let's Encrypt makes some aspects of it easier but until the amount of fiction is similar to the process of deploying HTTP you'll never see HTTPS ubiquity in my opinion.
granted, you're already giving up this control when you host with any 3rd party, but the CAs are being reckless if they encourage it.
Try Caddy with automatic HTTPS [0] in reverse proxy mode [1].
That aside, your site looks at valuable resource. Thank you for publishing it.
Personally, I'd deploy HSTS incrementally and wait until such time there is a majority of subdomains that are TLS capable before deploying includeSubDomains. Otherwise, there could likely be some nasty surprises.
Arbitrarily enabling includeSubDomains is going to lead to nasty surprises if there is no prior coordination.
I'd argue that all, not most, subdomains must be HTTPS capable (I won't say TLS generally, either; this is only dealing with HTTP). Any that aren't will not be accessible by a user agent that recently (within the max-age) visited the parent domain if it had an HSTS header with that flag.