Enabling overflow-checks in Rust release builds: what breaks and what it costs

Rust's default Cargo profiles create a documented divergence: the dev profile sets overflow-checks = true, so integer overflow panics during local testing, while the release profile sets it to false, so the same arithmetic silently wraps in production binaries. A service can pass every local test and still ship code whose overflow behavior was never actually exercised under production semantics.

I am deciding whether to set [profile.release] overflow-checks = true for a long-running network service, and the trade-offs are not obvious from the documentation alone. The Cargo manual confirms the flag is independent of optimization level, but says little about real-world impact.

My specific questions:

• For CPU-bound services, is the runtime overhead of release-mode overflow checks typically measurable enough to matter, or is it lost in noise outside tight arithmetic loops?
• If I enable it, should code that intentionally relies on wrapping be migrated to explicit wrapping_add/checked_add APIs first, or is it acceptable to let the panic surface latent bugs?
• Does enabling debug-assertions alongside it compound the cost, or are they cheap enough to keep in production?

Assume stable Rust with Cargo's default profile behavior; I can verify defaults against the Cargo manual and benchmark locally, but want to know what others weigh before flipping the flag.