A long time ago PHK wrote some very salient comments about HTTP 2.0 efforts https://varnish-cache.org/docs/trunk/phk/http20.html https://queue.acm.org/detail.cfm?id=2716278 etc. He puts forward the case for a browser-picked client-session-id instead of a server-supplied cookie.
It's not that the developer is the enemy.
Pretend I create a website called "Democratic Underground: how to foster democracy under a repressive regime." I'm naive, or I want it to load quickly, or I accidentally include a framework that is either of those two -- some library versions are cached.
Now, the EvilGov includes cache-detection scripting on its "pay your taxes here" webpage. Despite my salutatory goals, shared caching leaks to the government some subset of my readers.
The browsers have always allowed cross domain requests which have been tolerated until now but involved all of us being aware of XSS and CSRF issues, or suffering the consequences.
Removing shared cache is the beginning of the end for cross domain requests by default. The other obvious use these days is ad networks, but they also get used for integrations like SSO and shared services like Apple Pay and presumably PayPal? And other collaborations between companies.
But those could also be opt in.
a) the origin sharing the resource must place a .well_known/static_resource file in place.
b) The presence of .well_known/static_resource prevents any request on this origin to send cookies, and any set-cookie header is ignored.
c) The document that includes the resource on this sharing origin must use subresource integrity attributes when loading the shared resource.
d) the resource cannot be cached unless the cache-control header is public and has a lifetime of at least 1 hour.
This guarantees that the resource is always requested cookieless, and that the resource can't vary per request, otherwise the subresource integrity check would fail.