Hi @mrtroll,
There have been a number of great answers to your question (Thanks everyone!) but I wanted to add one more.
The protocol that Let's Encrypt implements that defines the methods of domain validation available for prooving ownership of a domain is called ACME. In fact your feature request would have to be directed to the IETF working group responsible for ACME since Let's Encrypt implements the challenges that ACME specifies.
ACME as it exists today specifically excluded email validation during design because it is commonly believed to offer considerably less security against miss-issuance than the other challenge types that were specified as part of the protocol.
This turned out to be the right decision and was reinforced by the results of an academic effort by HAL-Inria in France. They produced a paper called "A Formal Model for ACME: Analyzing Domain Validation over Insecure Channels" where they used pi-calculus to mathematically model an older version* of the ACME protocol. The results specifically highlighted how the protocol would be weakened by adding email validation:
Unlike HTTP and DNS Identifiers, Email Identifiers effectively offer C a read-based challenge instead proof of some write access. In §3, we discuss how Email Identifiers are the weakest available form of identification given our threat model.
I think it's extremely unlikely that the ACME working group would be willing to revisit the inclusion of email based validation in light of findings such as this. Similarly Let's Encrypt would not implement domain validation challenge methods that were not part of the IETF ACME protocol.
Hope that helps explain things!
*: Other findings have either been addressed in current versions of the protocol or were things from early drafts that Let's Encrypt never implemented (E.g. account recovery)