The URL could point to an image, a movie, a web page, JSON, etc. The only thing it does not make easy/practical is passing large data chunks inline.
As to the latency: if large data isn't available locally, someone will have to take a hit. I do not see why severing this to the provider would be problematic.
If it is available locally, I would hope that the intent provider can retrieve it from cache.
Also, deferring the loading enables optimizations. Suppose I see an image on example.com that I want to share using Flickr. If I send the URL to Flickr, it can retrieve the image from example.com using its fat Internet pipe. If, instead, I have to send the image, I have much more upstream data. Even at home, that can be problematic. Mobile, things are worse.
"mailto:" is a protocol that is interpreted by the user agent, to launch the user's preferred mail client. We could also have "share:", to launch the user's preferred way of sharing things.
So why not this?
It's a bit odd to have the protocol wrapping what looks like another protocol, but it's legal. One might even have the convention that an empty share means the current url. Then it would be just