They seem a lot more useful for internal infra of hosting providers, though for IPFS in particular I expect the performance isn't consistent enough to be a suitable solution for most of those use cases.
Plus the gateways provide compatibility to www.
Given, things are far from ideal now. But looking over the water it's good to see Mastodon taking off and I think that's largely because you have the option of just choosing a single trusted provider ("instances") from which you can access the rest of the network. The trusted provider does the heavy lifting for you.
I think of IPFS as being an open data platform first. You can connect to it and disconnect as frequently as you like. The underlying p2p capabilities don't have to necessarily be fast. It just has to do the job it was designed to do—get content in a permissionless fashion.
Speed, convenience, reliability, and more are not the problems protocol need to solve for. Providers can solve for these problems without infringing on your ability to "take your ball and go home." Take Pinata for example. We provide dedicated IPFS gateways that provide essentially the same experience you would expect from traditional cloud providers. But if you ever want to leave Pinata or back your data up or just inspect your data, you don't need Pinata's permission. IPFS media is public and open. Convenience is a layer on top of that.
IPFS also doesn't need or have tokens. Filecoin is a separate entity. IPFS is especially powerful because it is not linked to a specific blockchain or currency.
They can't if the protocol doesn't allow it.
Otherwise it will be regular centralized storage providers with IPFS bolted on top for one or two geeks who care about it.
Because IPFS links are not URLs, it works on a different paradigm.
The chance of somebody storing your HTTPS files and IPFS files is the same. Users pay hosts to keep hosting them. With IPFS, if the user stops paying the file hosting service, another user can pick up the slack without the link becoming dead.
Too much faith in someone picking up your files when a centralised host goes down. This is an important detail that for some reason is always dismissed by IPFS proponents.
But if another party is interested in the file, they have the option to persist the file regardless of what the original party and centralized services choose to do.
What does IPFS bring into the picture apart from "oh yeh, there's a near-zero chance that someone will keep hosting your file"?
1 - A content addressable URI protocol that allows you to locate a file without linking to a singly-owned and named server or host. This is not the case with HTTPS URL protocol.
2 - Open source clients where multiple parties, including competing parties and individual users, can all simultaneously and permissionlessly peer-to-peer host an asset behind the content addressed URI.
My uneducated guess: content in IPFS is split in too small blocks, making the data-to-control ratio way too low.
It wasn't until maybe 10 years ago that I finally got my answer: It turns out that Amdahl's Law kills AFS. There's a total throughput wall that becomes very painfully visible once you move to gigabit networking, and any one client can pretty much saturate the network.
It could be interesting idea on smaller scale, say you start a "virtual hosting provider", where each of 10, 100, 1000 people connects into a mesh and store eachother's data so in event of failure it just keeps working.