What if you had a declaration like @font-face { font-signature: somehash } And the browser just checks to see if it already has the font. If you release a webfont you can share it with signatures or just generate signatures if the author hasn't done it for you. This way if you're self-hosting Lato and the user already has Lato, they don't need to download it again.
Think of all the big JS frameworks. If they were all referenced by hash, their size would become pretty much irrelevant, as they would be amortised across potentially thousands of requests.
But the web chose to go with unified resource LOCATORS for everything, and I don't think it'll be easy to change that mindset.
It's the reason why people do crazy things like register DOI (a location based URL, that is hosted with a single point of trust/failure) to reference git hashes (a content addressed URN). They don't know better, and they want readable names.
A different issue with this kind of caching tho is that it is a potential side channel for privacy sensitive information.
For example if my script requests the pornHub logo, or something else that might even be more specific, like videos themselves. I can use a timing side-channel to figure out wether or not that particular item was in the users cache, and thus visited previously.
Imho they applied the wrong solution to that issue: domain separated caches. You loose the timing channel, but also loose all the caching advantages.
A much better solution would have been to close that timing side channel. If every browser ran TypeScript this could actually be a monad, where a "low resolution timer"-monad is strictly separating timing sensitive portions from high resolution timers.