I apologize in advance for the long read - I have tried to reduce it but there are just too many thoughts…
If you are implying that P-384 and P-521 won’t/can’t be similarly optimized then that needs to be looked into further. Otherwise, I expect both will be optimized similarly as they become more mainstream (soon enough).
Based on this line of thinking the CA would decide “which is best”; And choose for us all.
Withstanding the optimization difference, I believe this line of reasoning is outside of the purpose of a CA.
Encryption should not be chosen based on what hardware can do. Standards dictate security.
Once this current choice is made and implemented (whatever it may be), it will likely take years to make another such choice and implementation; So, we need to consider where things might be that many years from now… Why chose today’s bare minimum? How will that minimum stand the test of time?
Also, the “decision” should be up to the consumer, not the CA.
Current LE RSA offerings are from 2048 to 4096 bits (and literally almost all numbers in between). [That’s hundreds of RSA size choices]
ECDSA isn’t quite as granular, there are basically only 3 choices on the table (2 of which are “supported” by LE - although presently not “end-to-end”): P-256, P-384, P-521.
We can all see that RSA has a much higher verify rate than ECDSA [at comprable “Strength”].
Conversely ECDSA has a much higher signing rate than RSA [at comprable “Strength”].
So the real decision is which one works best for a specific customer… in a specific circumstance.
But only the customer can answer that.
Some may be OK with 3DES, or 1024 bit DH, or 2048 bit RSA, or not using PFS, etc.
We shouldn’t be making these (nor any) choices for them; nor setting restrictions where they are not needed.
To me this is really about providing more choices to a world that doesn’t easily fit into a one-size-fits-all system.
Security is a double edged blade: You can’t easily move in any direction without cutting something…
When you move towards more security you cut speed; When you move towards more speed you cut security.
[It is a very rare case that you can move towards one and also increase the other (we call that a “no-brainer” or “win-win” - but they are few and far between).]
I am no longer comfortable with anything “256 bit”; Simply because things like BitCOIN mining use ultra optimized systems to crank out trillions of operations per second on 256 bit hashes. In that light, I would not want to use a cipher that a single optimized system can generate millions/trillions of such signatures per second. Brute force attacks would soon rule the day. So, yes, I find some comfort in knowing that when it can’t be done soo easily, the bad guys also can’t do it so easily.
What it comes down to is the customer weighing the options and understanding what the impact of those differences can be before making an educated decision and/or being able to easily change their decision as things change within their particular circumstances.
In summary: When more is better, I say “Give 'em more!”
[If it wasn’t obvious, I always sit on the “security side” of the table.]