There sometimes may be an excuse in the extra roundtrips required to set up a TLS connection. For a public blog that doesn't accept submitting any information (like comments), for example, plain HTTP may be fine.
HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.
Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.
On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.
Highly recommend this blog post [1] for more.
[1]: https://timtaubert.de/blog/2015/11/more-privacy-less-latency...
Injecting ads, changing content. All possible when the content isn't encrypted end-to-end.
TLS is not about accepting information, it's about ensuring that the connection's encrypted and authenticated.
It is still important to prevent unauthorized third parties from watching which articles you're reading. And it's still important that you know that you're reading a blog you expect to read, not a modified version served by someone else (although CA system isn't completely sufficient for this, at least it thwarts less-powerful adversaries from spoofing).
These types of attacks have been hypothetical for a long time, but we're starting to see real world impacts of not using https, and they aren't trivial.
The Greek government inserting ads into that site is very low on my list of concerns, but the additional 200-400ms on the first page load is much higher up.
Am I correct in understanding your point as "there can be no conceivable case where two fewer TCP roundtrips would be worth the speed gain over the decreased security"?
Unless someone care about a single extra round-trip timing, e.g. extra 10-300ms with 300 being quite a stretch? I'm sure it doesn't matter if a blog page opens in 40ms or 55ms - a reader won't tell the difference.