If its easier to use than bittorrent then piracy people will switch over too and soon the name sounds just as frightening. The problem with bittorrent wrt popularizing legal use was that browsers should have shipped with BT support, the experience would have been just like clicking a traditional download link.
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.
The JS approach is still more cumbersome than a normal download, which just asks for a destination right when you click the link (if at all, I think most browsers default to just starting to download to a default destination nowadays).
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.
Yeah, browser integration is critical. That’s why IPFS has focused on the JS implementation.
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.
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.