> If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies.

Weakness in the protocol, but not necessarily weakness in the system as a whole. This is an environment where part of the trusted nature of the system comes from having a complete record of all the network communication to and from the system, and an ability to audit that data offline.

That context is in conflict with the objectives of PFS & TLS 1.3 in general. So, understandably, they came up with another solution that fit the design goals, and understandably, rather than reinvent the wheel, they came up with a way to tweak existing solutions to fit their design goals.

> You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints.

Yeah, you're not understanding the system. The whole point is to NOT trust the endpoints to be reliable narrators of what they are transmitting over the network (which makes sense, because if they are compromised, they wouldn't be). TLS is designed to allow two trusted endpoints to communicate, but the goal/context for eTLS is to have a full audit of communications into and out of an untrusted node. That's presumed from the start; TLS's goals therefore aren't helpful.

Which means this whole argument might be insincere and the real goal is otherwise.

Lack of PFS isn't a weakness. It isn't a mathematical backdoor. It's a config option that is left disabled when entities have a moral and ethical rationale for inspecting the traffic traversing their network.