No. Let's Encrypt is focused only on the Web PKI. So that includes web servers (obviously), and everything that speaks TLS on the Internet (e.g an IMAP server for your email) but it doesn't include either type of end-to-end email encryption (S/MIME or PGP), nor any kind of code signing, document signing, timestamp services or similar.
Technically this is implemented in two ways. One: Where Trust Stores themselves have distinct trust for different feature sets, ISRG/ Let's Encrypt asked only for the flags needed to do Web PKI. e.g. In Mozilla they didn't ask for S/MIME or code signing (today Mozilla doesn't do code signing anyway).
Two: Certificates have a section called Extended Key Usage (EKU) which can list arbitrary purposes for which the certificate's issuer says the Public Key included in this certificate is to be used. EKUs on Let's Encrypt certificates specify two purposes, 1.3.6.1.5.5.7.3.1 (TLS Server) and 1.3.6.1.5.5.7.3.2 (TLS Client) so these certificate proclaim themselves not to be suitable for other purposes.
As zimmerfrei said, it allows one webserver to connect to another (e.g. a load balancer, with a certificate, to connect to a backend webserver) and present that cert to the server it is connecting to.
Without the client EKU bit, a conforming TLS implementation would reject the connection.
