This really depends on what you are worried about, I think it would be best to separate an internal attacker and an external attacker:
An internal attacker wouldn't have much need for the certificates, if they can pivot around they can get pretty much any information they need. I haven't come across any incident reports where the attacker go after network traffic instead of just "smash and grab" stealing information right there, and credentials from disk or memory. And i can't see much need for it either: if they had foothold in the system, they could probably do their own thing doing targeted TLS interception with something like WPAD + SSLStrip/Polarproxy.
An external attacker with access to the signer certificate could decrypt traffic assuming they have access to a full enterprise pipeline of packet captures (which is a crap load of data, i assure you) with close to zero packet drops. But unless they were capturing all network traffic earlier, they would only be able to decrypt traffic from the time of compromise.
Access to client certificate (with the public key) either installed locally on a device or sent as part of negotiation from the TLS interception proxy really does not help much, you can do trial encryption and compare outputs but that is in the realm of theoretical attacks and not something applicable that an attacker would do.
TLS intercepting proxies are quite valuable for DFIR, I'd say that they are essential today, their usefulness easily outweigh the risks, and some even allow for exceptions can be made for banking sites. But such devices also need to be locked down, not just technically but also physically, so don't place such a device in an open broom closet near the visitors entrance.
But as Angel said: if this scenario happen, you have a much bigger problem.