The scenario this prevents is common and costly: you send an order, the connection drops before the acknowledgement returns, and you do not know whether it reached the exchange. Retry blindly and you may now hold double the intended position.
With a client-order-id that the venue enforces as unique, the retry is rejected as a duplicate rather than executed, and you can query by that id to learn the true state. Most serious APIs support this; many people do not use it.
The rule extends to cancellations and modifications. Every state-changing request should carry an id and be safe to repeat, and the system should be able to rebuild its view of the world purely from querying the venue after a restart.
Related: client-order-id, order-reconciliation, api-rate-limit, kill-switch