Why is the Post/Redirect/Get pattern not sufficient on its own to prevent double-click duplicate submissions?

Post/Redirect/Get solves a specific, later problem: it stops a browser from re-issuing the original POST when the user refreshes the page or clicks back after the first submission already completed and redirected. Because the address bar now shows a GET URL, a refresh just re-fetches that GET, not the original POST.

Double-clicking a submit button is a different, earlier problem. Both clicks fire before the server has had a chance to process and redirect from the first one - two POST requests are dispatched to the server essentially back to back, often only milliseconds apart, well before any redirect response exists to protect against. PRG has nothing to say about that window at all, since by definition it only comes into play after a successful redirect has already happened.

That's why a double-click specifically needs either a client-side safeguard (disabling the button immediately) or a server-side one that can reject a second concurrent request before it's fully processed (a synchronizer token invalidated on first use, or an idempotency key check) - PRG addresses the resubmission case, not the concurrent-double-dispatch case.