Which rejection policy would you choose and why?

AbortPolicy (the default) throws RejectedExecutionException, which is honest: the caller learns the system is saturated and can shed load, return 503 or retry.

CallerRunsPolicy runs the task on the submitting thread. That is a throttle with feedback: while the web thread is executing a task it is not accepting new requests, so the pressure propagates back to the client. It is the right default for an ingest pipeline, and the wrong one where the caller is an event loop that must not block.

DiscardPolicy and DiscardOldestPolicy drop work silently. That is acceptable only for data whose loss is genuinely fine, such as sampled metrics, and it should be counted so the loss is visible. Whatever you pick, a rejection counter on a dashboard is what turns this from a guess into an operational signal.