The Web PKI is hierarchical, but it isn't particularly centralized (other than Let's Encrypt increasingly eating everyone else's lunch, which is probably a good thing).
But in terms of actual failure points: if you're initiating a connection over HTTPS, then the only way an attacker can MITM you is by convincing a CA to incorrectly issue them a certificate for that domain. That's why Chrome and Safari monitor certificate transparency logs, and why website operations should also generally monitor the logs (to look for evidence of misissuance on their own domains).
I'm sure there is some nuance to what someones static site is serving but someones blog doesn't need to be HTTPS. If they are offering downloads you can provide checksums or verify their data through other sources or contacting them out-of-band.
Anything that needs some form of validation from any site should be verifiable in multiple ways. Just because they have HTTPS doesn't mean the provided information or data is automatically correct.
The attack you are suggesting is not commensurate to the types of blogs and information that _need_ HTTPS.
If you are operating at a level where your personal blog can have all possible transit paths compromised by a third-party such that they are hosting some or all resources that you provide for download, modifying them and producing new checksums then you have bigger problems than a blog that doesn't have HTTPS. You would also at that point consider using someone else's platform that will absorb or actively be motivated to thwart these exact scenarios. Not to say that always works out[1].
Additionally your concern of checksums being compromised can easily be thwarted by hosting packages on github, gitlab, bitbucket, pastebin, or a google groups mailing list. All of which still don't require your blog to have HTTPS. You don't have to manage getting your own certificate, paying for yearly renewals or setup any auto-90-day let's encrypt auto-bot.
Great grandma's cookbook recipes on a blog don't need HTTPS.