Since they have the key for their own certificate, they can man in the middle forward secret connections too (these days, ECDHE). By supporting only non-PFS RSA key exchange with TLS 1.2, they had the ability to retroactively decrypt traffic without doing full man in the middle. Maybe they mirror a port on a switch and run an IDS/antivirus that decrypts the traffic and analyzes it. Maybe they log all traffic for a while and want to decrypt it only if needed.

In any way, the solution someone came up with was to do Diffie Hellman but reuse the ephemeral key (make it static) and share it with the decryption box. This turns (EC)DHE into not forward secure key exchange. The client can notice this happens because the server will reuse the DH key. I didn't hear about any browser planning to warn the user about this. The ssllabs tester will complain.

If you are using a non-forward secrecy supporting implementation, such as RSA, the SSL key on the server is all that's required to be able to decrypt the conversation.

That's why you can use Wireshark in the manner described here, by installing the SSL key on your client machine, and decrypting the whole session:

https://support.citrix.com/article/CTX116557

You'll note the article warns, it won't work with DHE. Similarly, it won't work with ECDHE. Modern forward secrecy ensures that even with the key, an attacker is constrained in their ability to decrypt the ciphertext.

I can only assume the industry request was based on running this sort of thing at a larger scale.