It all comes down to your security requirements, user choice, and risk of implicit downgrading. Disabling old ciphers server-side is largely necessary because browsers will happily fall through to absolutely horrible ciphers client-side in the name of user experience/convenience. Making sure nothing of yours that depends on a secure channel to the user cannot be reached with an insecure method is, of course, also very sound.
Not allowing me to to explicitly downgrade to insecure HTTP when I've deemed that your blog post about why you like Python more than Ruby (not saying you do, just a generic example) isn't something I mind the spooks or the public knowing I accessed is just getting in my way for no good reason, on the assumption that HTTPS will be trivial for me.
There are, today, embedded systems which don't have the ability to use TLS out of the box, or ones which are stuck on old implementations (I think it's awfully bad that this is so, but as a power user of [insert embedded device here], I sometimes can't change this).
Here's a fun experiment: try downloading a recent version of LibreSSL from the upstream OpenBSD site over HTTPS with a sufficiently old TLS/SSL implementation. You won't be able to. I tried the other day on a device with an older OpenSSL build from 2012 or so, because I wanted to upgrade this embedded system to more secure, new stuff from source - I don't have the luxury of a prebuilt package. The error messages when I tried weren't exactly intuitive, but I presume it was because my older OpenSSL didn't support the right stuff.
This is one example where the move the only-HTTPS can actually detriment people: if you don't have the luxury of recent pre-built packages and want to fix the problem yourself by building from source, you're locked out. Thankfully, in the LibreSSL case, you can fall back to explicitly requesting HTTP. Sure, this won't save you from an attacker already rewriting your traffic, capable of replacing source packages with compromised versions and rewriting all checksums in HTTP bodies describing the packages available for download on the webpages you browse, but it's still useful in the much more common case.
Most of us aren't one unsecured download away from being owned by an APT (Advanced Persistent Thread: security jargon for national intelligence agencies and other extremely well-resourced cyber threats). Sometimes I just want to
wget some plain text documentation or a small program whose source I can quickly audit (my own tiny utilities/scripts on GitHub, for example) onto a box that doesn't support the most recent cipher suites.
Personally, I'd ask this: is your content such that a person could legitimately decide "I'm okay with me accessing being public knowledge"? Is there a plausible chance of real risk to non-technical people accidentally downgrading to HTTP for your content? Weight your security requirements, enforced-privacy-for-your-users requirements, and risk of implicit downgrades against the ability of users who understand the risks making an informed choice on a case-by-case basis to go unsecured. It's entirely legitimate to say that for your site, there's no good reason to not enforce HTTPS - but I think it's fair to say that there are still good use-cases for plain HTTP out there.