People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys.

Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa).

Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature.

The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.

It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use.

If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key.

They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.

Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.