Out of gas on deployment: should a low-traffic contract trade revert reason strings for custom errors?

I am finalizing a small Solidity contract that will be deployed once and called only occasionally, so the dominant cost is deployment rather than per-call execution. Since an out-of-gas failure consumes all supplied gas while reverting state, I want the deployed bytecode as small as reasonably possible before I commit to a compiler configuration.

The documented tension I cannot resolve is around error handling. Custom errors (available since Solidity 0.8.4) are cheaper than revert reason strings, because strings are stored in the deployed bytecode and ABI-encoded at runtime. But switching to custom errors means off-chain tooling must decode a 4-byte selector instead of reading a human-readable message, and identical selectors across contracts can be misattributed by decoders.

There is also the optimizer runs parameter, which trades deployment cost against call cost; with uncertain future call volume I am unsure what value is defensible.

My questions:

• For a low-traffic contract, does removing revert strings in favor of custom errors meaningfully reduce deployment gas, or is the saving marginal compared to overall bytecode size?
• How do teams handle frontend and monitoring error decoding when the human-readable string is gone?
• Given unknown call volume, is there a reasonable default for the optimizer runs setting, or should I benchmark both extremes?