Yes, and no.
It's a root cert that chains to another root cert (thus the term "cross-signed").
Some systems will short circuit the chain verification (stopping once they have found a trusted entry) and some don't know that CA and continue onto the next link in the chain (the other CA).
Another way of explaining this is based on the ROLE each certificate plays in the path:
The third "cross-signed root certificate" is included to handle situations in which the "ISRG Root X1 Certificate" is not available in the local Trust Store. In these scenarios, the "cross-signed root" does not function as the CA Certificate (or Trusted Root Certificate), but instead as an (Untrusted) Intermediate Certificate. The "Trust" comes from being (cross) signed by the DST X1 Certificate, which will act as the trusted CA Certificate.
I think that is a very helpful way to describe it, @jvanasco.
It's fair to say that Let's Encrypt's strategy here is unusual in comparison to more commonly encountered trust chains, because of the DST root certificate expiration last year. Most trust chains do not attempt to rely on expired root certificates.
@yufeiluo, the reason for this unusual situation is that Let's Encrypt determined that it could help to maximize compatibility with older devices that do not receive software updates. This is a complicated discussion which was analyzed in some detail here on the forum last year, in topics related to the DST root certificate expiration. It especially has to do with the behavior of Android clients.