An honest retry and a genuinely new request look identical without one
A network failure often leaves a client unable to tell whether its request actually succeeded before the connection dropped — the request could have completed on the server and only the response been lost, or the request itself might never have arrived at all. Retrying is the only reasonable response to that uncertainty, but a plain retry, with nothing distinguishing it from a brand-new request, risks executing the same consequential action a second time if the original attempt actually did go through.
An idempotency key, generated once by the client and reused on every retry of that same logical request, gives the receiving system what it needs to tell the two cases apart: a request carrying a key it's already processed is recognized as a retry and returns the original result, rather than being treated as a fresh request and executed again.
Why this is fundamentally an authorization concern, not just reliability
At-least-once delivery — a guarantee that a message arrives one or more times, never zero — is a common and reasonable design choice in distributed systems, precisely because achieving a stronger exactly-once guarantee is expensive. But it pushes the responsibility for correctness onto the receiver, which has to treat every incoming request as a possible duplicate. Without idempotency built in, ordinary network unreliability can end up authorizing the same consequential action twice, purely as an artifact of the delivery guarantee rather than anything the requester actually intended to happen.