This will protect you from replay-attack. Lack of such implementation will allow an attacker to successfully authenticate as many times as he wish, until the passkey for which a request was compromised is revoked on 'server' side.

This is why standard requires you:

1. challenge:
   • MUST be randomly generated by Relying Parties in an environment they trust (e.g., on the server-side)
   • MUST contain enough entropy to make guessing them infeasible
   • SHOULD therefore be at least 16 bytes long
2. returned challenge value in the client’s response MUST match what was generated [on the server side]
3. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete.
4. Tolerating a mismatch will compromise the security of the protocol.

See https://www.w3.org/TR/webauthn/#sctn-cryptographic-challenges