One main benefit of https is confidentiality, but for OSS downloads it more importantly provides an integrity and authentication benefit as well. Sure checksums and/or package signing should provide the same benefit, but most users cannot say they have checked these for every installation (and checksums are useless if served via http because they can be tampered via a man-in-the-middle attack).
I really do wonder whether there's a verified "path of trust" where I can get a copy of e.g. Debian (without knowing what the canonical website for Debian is), install it on a machine, connect it to the internet and update it, without being at all vulnerable to a MitM attack at any step.
I would be suspicious that it's the very first step that poses the most danger: there's little way to know whether minor-distro-X is "properly" hosted at minordistrox.com or distrox.org or even distrox.github.io, other than by blindly trusting the relative PageRanks of each.
---
Something that would be very nice, I think, would be a way to rely on the package-signing infrastructure of the OS you've already got (and trust), to guarantee for you the copies of any new OS images—even for different OSes!—you download. Sort of the same way you download new versions of OSX through the Mac App Store, but going a bit further.
Now that I think about it, the browser-preloaded HSTS list might do the trick... if it was coupled with a mapping of 'important well-known downloads' to a single (HSTS-preloaded) domain you should be allowed to get those downloads from. (Presumably with heuristic detection, so it could find "something looking mostly, from its metadata, like a Debian ISO image.") Then your browser would just tell you you're being phished if you're trying to get a Debian ISO from debianisamazing.info.
This is true, and MitM attacks are becoming less and less theoretical as more traffic moves to the various wireless protocols. Rogue AP's and cell towers are a thing in these modern times.
You can validate the certificate used to establish the connection and thus the endpoint, if you want to, and thus avoid one potential vector of someone serving you a malicious postgres build. Because you're putting your trust in the network.