It's possible that they could start issuing separate certificates upon specific request for code signing purposes, but it's doubtful they would be willing to meet Microsoft's requirements for such certificates, so their code-signing CA would not be added to Windows's trust store, rendering the certificates it issues useless.
The ACME protocol, the key automation technology that makes Let's Encrypt possible, performs domain validation only. It verifies that you, the person (or bot) making the request, are an authorized administrator of the DNS records, or port-80 HTTP server, for that domain. This is directly relevant to, and generally considered sufficient for, HTTPS.
However, domain validation is almost completely irrelevant to, and insufficient for, code signing. Microsoft's rules (and Apple's, incidentally) require establishing the identity of a legal person (individual, or preferably, company). There is no way the ACME protocol can do this, which means that the process is totally out of Let's Encrypt's wheelhouse.
It's actually the only thing that provides any kind of assurance to users. It's not like end users know if FuzzCo is the correct developer for FooApp but they know fooapp.com.
There is nothing in a piece of random software obtained from some random source that authoritatively connects it with a particular domain. Without bringing an App Store or other walled garden into the picture, the operating system must evaluate an executable file according to the contents of the file itself. On cold launch, the information in the certificate can be presented to the user, and the certificate issuer can be checked against the O/S trust store, but nothing equivalent to the HTTPS domain check can be done.
DV certs work for the web because of that intrinsic connection between web site and domain. They fail for arbitrary software because of the lack of such a connection. The trustworthiness of code-signing certs comes from the relatively difficult process necessary to obtain them, and not the name attached to them. The identifiable legal entity to which the certificate was issued is more useful to the O/S vendor, as a harder-to-evade ban target, than it is to the end user.
Pretty sure there were historically a lot of apps that stole peoples contact lists and were signed properly. Certainly in the Android world.