That's an interesting point. I did take it for granted that browsers guarantee web apps that they don't send the URL fragment to the server. I've never looked into it, but your comment sent me to read RFC 3986.
From my reading, the RFC does seem to prohibit browsers from sending the URL fragment:
>Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing... As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.
Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful interpretation on the RFC.
I agree that if I were storing, say, military secrets, I wouldn't choose the URL fragment as a storage medium. But if the expectation is "this is a place where I can put user data and the browser won't leak it to other places," then the URL fragment seems to me a sensible place to store data, on par with browser local storage.
This is in contrast with plain URLs which third party servers receive through the HTTP referer header. The browser leaks query parameters to other places, too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a system that exposes URL fragments to an external service.