Well, that seems like exactly the difference: It's not about obscurity, it's about curl not being a daemon and therefore a poor fit for p2p protocols.
Also, the Internet Archive uses web seeded torrents to accomplish the problem of insufficient seeds rather than throwing them into the ether (non-crypto variant) and hoping for mirroring by wishful thinking.
Conclusion: Centralized, unicast-like support for p2p is possible and useful for download-oriented clients.
IPFS Desktop in particular: One shitty thing they did was auto re-opt-in to telemetry without asking the user. With that kind of sneaky bullshit, I refuse to run it. IPFS lost trust and is unable to communicate how their "solution" is useful or make it usable by humans who aren't IPFS Desktop developers.
P2P protocols like IPFS are built with the expectation that clients are persistent. They take a nontrivial amount of time to start up (e.g. to discover peers), and require continuous maintenance from the application to keep running (e.g. to chat with those peers and keep them happy).
These characteristics are incompatible with clients like curl. They're written with the expectation that connection setup is cheap and that connections don't require maintenance while they aren't being used. These expectations are all true of existing protocols like HTTP(S) or FTP; they fail with IPFS. And there isn't really any way to solve that without introducing another process to act as an intermediary -- which is exactly what an IPFS gateway does.
There are stable nodes to bootstrap a new node into the network. More initialization that if you were using http, sure, but it isn’t as against the grain as you suggest.