SSL certificate doesn't confirm validity, reliability or credibility of the related party. It has sole purpose of encrypting data transaction between two terminals. (Like one being a server which hosts a web site and another one being your browser by which you browse that website.) (A note: there is also Extended Validation (EV) SSL but that's another point.)
So there is absolutely no reason to distrust Let's Encrypt SSL because there is absolutely nothing different between Let's Encrypt and any other certificates you paid for, in terms of what they do.
And for that matter, there is also nothing different between self-signed certificate and any SSL you bought. For example there are many public and government intranet applications which use their self-signed certificates, just to encrypt data between terminals. In the end, if you can trust yourself, then you can issue yourself a certificate, can't you? Your application can perfectly work with this certificate just like it would with Let's Encrypt or a paid one.
The only difference with using your own-forged (i.e. self-signed) certificate is that your system will probably require you to store your Certificate Authority (CA) certificate in the certificate pool of your system; because the system won't recognize you as a CA automatically. Systems are set to use a predefined list of these authorities to "automatically trust" the certificates they issue. This is the only difference.
I am not saying "you can use self-signed certificates in your web site". And I am not saying we can use our own certificates and everyone should add us as a CA in their pools. I am just saying there is no technical difference in the certificate. As there are many intranet applications of which the authority usually asks you to add them as a trusted CA in the user's pool. Like for example a government agency uses a self-signed certificate for their application and asks their users to download and include their CA certificate in their pools. I know some entities do it for even public applications.
If your client had an old system which required more manual work, once they add Let's Encrypt as CA in their system, they shouldn't be asking you to send the certificate each time after renewal; because their system should recognize the issuer already. There must be something very specific to their system. So no, it's not common practice.
You can understand from here that it is not important that the browser is warning you that your certificate is insecure. Because it doesn't actually warn you about the certificate itself; it is warning you that it didn't recognize the issuer. (Of course we are talking about a valid self-signed certificate here.) To test this, just change your computer date to 50 years from now. And refresh this very page and your browser will tell you the certificate of Stack Exchange, this very site, is insecure. Well, is it? It was secure a second ago? The site and the certificate didn't change; but the browser recognized the validity period and thought that it is expired.
This is also why you don't usually use self-signed certificates on web sites. Because you can't hardcode yourself as a CA on the browser's list. That's the only reason why you wouldn't use it; but as you see, there is technically no reason why you can't.
To sum up, let alone distrusting Let's Encrypt, I think that it is a very very long overdue that the internet community didn't have it before. Free and automated SSL certificates should have been a standard years ago.