1. Performance. In terms of latency, this is adding an extra round-trip to each page request (to get the metadata). It's also likely going to load different resources from different servers (hostname, IP) preventing connection reuse. I guess they can't even start fetching data until the full page has loaded? And it feels like this scheme would make it much harder to reliably cache resources, since the browser will cache by URL while they'd struggle to make sure the URLs are stable across calls.
2. Privacy. Their threat model only addresses malicious peers changing content, not malicious peers trying to track users.
3. Economics. If running peer servers really was profitable, the company would do it themselves rather than outsource it. Given the "where can you get a server" section, it's not even that they're expecting this to just be running on spare capacity.
The problem with the setup is that incentives of the peers are badly misaligned with the network, the clients, and the end-user. A peer wants to maximize traffic; the clients and end-users want to minimize it. So a peer would be incentivized to set cache-control headers to prevent caching, to increase traffic. Likewise a peer would be incentivized to only keep copies of the most accessed resources, to be able to serve as high a proportion of the traffic as possible with a given disk budget, while all the other stakeholders would like each file to be available just N+1 times in each region.
4. UX. URLs will be really crappy compared to a proper CDN. Right-click copy a link to an image and send it to somebody? It'll initially be to some super-dodgy URL, and stop working in a day or two as the CDN node starts caching different content. And AMP showed that people do actually care about URLs.
It's pretty hard to take this seriously.