Let's Encrypt serves a chain up to the (now expired) DST Root CA X3, because that helps with Android compatibility. The current plan is to serve this chain until about 2024, though those plans may change at any time.
Most clients should have no problem with either chain - ISRG Root X1 is included in the current chain, and any validation algorithm following RFC4158 (and having ISRG Root X1 in the trust store) will use that as its trust anchor.
There are some clients - especially older versions of non-OS/non-browser related TLS implementations (OpenSSL, GnuTLS and others) that do not implement RFC4158 correctly. Those clients can verify the alternate chain, but not the default*.
For these clients, there are sometimes client-side workarounds available (removing the expired root from their trust store, enabling optional features....). Serving the shorter alternate chain server-side is a valid workaround server-side, but will break Android < 7.1.1.
*Assuming that ISRG Root X1 is in their trust store. Clients where this does not apply usually have issues with either chain, unless they ignore the expiry of DST Root CA X3 and the server serves the long chain.
Conclusively, both chains have advantages- and disadvantages. There is no solution for everyone.