"Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself."
So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e-mail encryption. That's annoying.
I don't think they're planning on changing that, according to later FAQ entries generating non-EC private keys is just too slow and it's the use of EC keys that causes the problem.
This is a huge problem that's akin to "replacing HTML/JS." It's a non backward-compatible change that make the plugin nearly 100% useless for current PGP users. Obviously folks can generate new EC keys, but they will be reluctant to abandon keys they've had for years that contain valuable third-party signatures. I think this will be a huge hindrance to adoption, and it would be imperative for the community to implement RSA, even if it's only for key import and interop, not generation.
Their workaround of "To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it" wouldn't make much sense if ETE wasn't able to import and interop with RSA keys already. You can also find an rsa implementation in the repo (https://code.google.com/p/end-to-end/source/browse/javascrip...) that would indicate that they do support RSA encrypt/decrypt. However I can't find any DSA implementation, I think there could indeed be issues with people using DSA/ElGamal keys. (which is weird because there is an implementation of ElGamal, probably the DSA implementation is still being worked on)
So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e-mail encryption. That's annoying.