If you want a technical document, try BCP #188 aka RFC 7258 "Pervasive Monitoring Is An Attack". That's a Best Common Practice document (ie it describes what the Internet Community should do) about the wide use of surveillance technologies such as "middle boxes" and it makes it clear that these are necessarily an attack in practical terms and therefore new Internet technologies should be designed to mitigate this attack.
BCP #188 made it easy to say why EDCO's arguments for RSA KEX in TLS 1.3 were unactionable. ECDO (the Enterprise Data Centre Operators, mostly big banks and similar outfits) wanted to use the obsolete RSA key exchange method in TLS 1.3, and sent somebody to argue for this right at the end of the process, years after it was removed - because otherwise they'd have to do a bunch of work, and who wants to do work? Well, too bad, RSA KEX makes surveillance really easy, so we got rid of it.
They got rid of RSA KEX but it was explained that using static DH you can still implement TLS monitoring. So they came out with ETS [1]. I'm sure there's vendors out there implementing this.
Having worked for a large telco that ran an oppressive network that performed TLS inspection on all corporate traffic, I imagine there'd be demand to inspect TLS 1.3 traffic. Banks, Boring Enterprise, Governments, Intelligence Community, etc. are the types of customers that are interested in this.
Here is a vendor implementing TLS 1.3 inspection [1] - they probably don't call it ETS (since there's a CVE attached to it) but it probably implements that exact spec (since ETS only deviates from TLS 1.3 by using a static DH key instead of ephemeral).
The second link even explains what they actually do, which is what we told them to do (but they didn't listen) many years ago in at least TLS 1.2 and probably TLS 1.0
It's a full proxy. Your client (say, Firefox) connects to their product, which has the real end entity certificate and keys for say, big-bank.example, which will have been provided by the customer who bought this product - and so it can prove satisfactorily that it is big-bank.example. Then the proxy forwards this to the "real" system which does the actual banking or whatever.
This is completely orthogonal to the TLS security design. We have successfully connected to you to a system which can prove it is big-bank.example. No need for static DH.
Should your bank trust third party suppliers with the ability to seamlessly impersonate them? I guess that's up to regulators.
BCP #188 made it easy to say why EDCO's arguments for RSA KEX in TLS 1.3 were unactionable. ECDO (the Enterprise Data Centre Operators, mostly big banks and similar outfits) wanted to use the obsolete RSA key exchange method in TLS 1.3, and sent somebody to argue for this right at the end of the process, years after it was removed - because otherwise they'd have to do a bunch of work, and who wants to do work? Well, too bad, RSA KEX makes surveillance really easy, so we got rid of it.