I thought software distribution would be a no brainer. There are plenty of projects that still have lists of mirror sites, using IPFS would be much better from a bandwidth and security perspective.
The distros are getting distributed over Bittorrent and since more people have it and know how to use it than IPFS, there is no point in distributing it over IPFS.
Today you have mirrors, tomorrow you could have multiple IPFS gateways, which would just take a hash and return a file.
Besides that, IPFS could be used to fill the BitTorrent niche -- so it would replace both mirrors and BitTorrent.
It's easier to use than BitTorrent and less frightening too.
One nuance - these p2p protocols are not as simple as HTTP, FTP, etc. They require persistent connections to many peers and significant local storage. This eats up more local resources, to the point where making in default-on might cause significant performance hit.
If you're talking about browsers acting as seed themselves, I don't think that model would get much traction, and the first thing people will do after downloading a browser is to disable that feature.
Nobody wants to keep seeding. This is the #1 problem for BitTorrent, and most people only keep Torrent on while they're downloading, so they never want it running all the time.
I think same goes with IPFS, which is why they came up with FileCoin, but if the mental cost of maintaining a node (because of all the copyright issues mentioned elsewhere on this thread) is higher than the actual profit each node makes, it will never take off. So in the end I think filecoin nodes will centralize just like Bitcoin nodes became centralized--that is, if they ever do end up launching what they promised--and when that happens it's AWS all over again, although the content addressable nature is indeed cool and I can imagine some cool applications coming out of it. It's just that I don't think it will replace HTTP altogether.
As for seeding, that would just happen while the download is going as you suggest, maybe have that configurable somewhere for the tech savy people. That would already scale quite well compared to no uploading at all with the traditional approach. The more demand there is, the slower the download gets, the longer you'll be seeding..
That being said, that's what would have helped 15 years ago, nowadays I'd agree that we're doing pretty fine with the centralized approach in most use cases.
There would also have to be a very high uptime guarantee, which means either every user of the distro operates a IPFS node by default, which nobody wants because IPFS is extremely chatty and there is such a thing as "servers in private subnets with limited internet access" that people don't want to send out arbitrary data to the internet. The next option would be opt-in, which means nobody will do it because everyone is lazy. Last option; simply maintain status quo.
These efficiency gains are real; major distributions should adopt this ASAP.
An IPFS mirror would also mean you'd have to run an IPFS node in a possibly corporate environment, which is a big nono if management doesn't allow P2P applications for whatever reasons. (Maybe they have their secret cure to cancer on their super secret server and don't want it to use the chatty IPFS protocols)