Could we work around this by moving encryption to the application/website layer with client certificates? Please let me know if you see any reason this wouldn't work.
You still have a bootstrapping problem. How do we establish what application-layer signatures are valid when a member state can forge a certificate for any origin at the transport-layer?
Ideally through hardware keys, but I see how that's hard to adopt. It's not entirely unrealistic though in the context of Play Store/App Store for the first download of an app from Google/Apple servers to be protected in transport by hardware keys.
Do the web browsers & operating systems face the same bootstrapping problem at the moment? At some point they must get their first certificate without using a certificate protected connection?
Edit - in the context of service which exists pre regulation, the client certificate could also be derived from the user's existing login credentials.
Of course they face that problem. It's a subset of the more general bootstrapping problem for a computer. So far, it mostly works as long as we can trust the hardware and we assume that the stack as we have it now is trustworthy.
As soon as you download and install an OS via an MITMed connection, it's over.
By using pre-shared keys instead of public key encryption. I'm not suggesting that is a practical solution for day-to-day use; I am saying this is how LE will be evaded, if this law should come to pass. So in effect, only criminals will have encryption.