Hi, Mark here. Author of the IPFS patch in Curl.

I see there's some doubt here about the usefulness of this patch so I'll go over a couple examples as to why this is great to have.

First an example of the same image in multiple centralized places.
Say you have a the same "cat.jpg" on 3 different sites (same exact byte size, same image). In a centralized world that would be:
https://someurl1.tld/cat.jpg
https://someurl2.tld/cat.jpg
https://someurl3.tld/cat.jpg

Which link do you pass to someone when sharing that? It's going to be one of those, if any goed offline your image will be perceived as offline even though it's there on other sites.

In a decentralized world with IPFS we can do the same thing through gateways. The gateway itself is a centralized endpoint through which you access content on the IPFS network. Here however the content of "cat.jpg" is hashed to a CID (Content ID). Let's say the content of "cat.jpg" has CID QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE

An example to get this same file on form the IPFS network through a gateway looks like:
https://gateway1.tld/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXf...
https://gateway2.tld/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXf...
https://gateway3.tld/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXf...

On a first glance there isn't much of a benefit.
You need a gateway url (a central endpoint) and you need to know the filename (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE).

Now for the curl approach and why this is awesome.
Your image (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE) is accessible through any gateway. But when you pass this information to someone else, you don't want to tell them to use one specific gateway. You only want to tell them the content hash (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE) and let them use their own gateway. You want that because it promotes the data to be propagated over the IPFS network and be better accessible.

The curl patch _prefers_ that you use a own local IPFS gateway. So when you receive a link like "ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE" it would use the gateway it has locally. And yes, this is just url syntactic sugar as it's all eventually been rewritten to a full http-url. If you have a local node with this patch it will probably will rewrite it to "curl http://localhost:8080/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxX..." But you could also be using an IPFS node in your local network but not on your local machine, meaning it could also rewrite it to:
"curl http://10.0.3.3:8080/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXf..." (or whatever your network is)

But to you, as the user of curl, that all doesn't matter. You just do:
"curl ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE"

Granted, if you use a node that isn't a local node the curl won't find it and you'll have to manually specify it in your local "~/.ipfs/gateway" file or in the "IPFS_GATEWAY" environment variable. But these are one-time configuration steps.

Another thing i want to highlight is malicious gateways and verifiable data. This patch really should be considered as a low-level syntactic sugar to access IPFS, not as full IPFS implementation. One can build on top of this and do data verification. This is, at least that is my opinion now, not a place for inside of curl itself. (assumption here) You can do a streaming approach and verify it block by block with another application, which should be a valid usecase. Also it's very much in the philosophy of building 1 tool for 1 job. Curl is to get data from network resources, something else is to verify that that.

Moral of the story is that passing and IPFS url like ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE becomes completely agnostic from central points. It becomes a local user setting to handle these urls. With IPFS still being young and still very much a niche technology, this is still somewhat of a hurdle to pass. But as IPFS gains more adoption like this, the hurdles become more and more streamlined to solve. At some point in the future people know that to use ipfs they install something that implements the ipfs protocol to use such links. Just like people know to use a webbrowser on http/https links, magnet links to be opened in a torrent client and mail links to be opened in a mail client (to name a few examples).