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.
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).
[1]: https://symantec-enterprise-blogs.security.com/blogs/product...
Edit:
Here's another vendor that probably does it too: https://blog.gigamon.com/2020/04/15/how-do-you-run-cryptogra...