I'm not affiliated with LE and I'm not an X.509v4 expert, but it seems the Extended Key Usage has been introduced to the intermediate certs in the most recent key signing ceremony: all previous intermediate certificates (X1 to X4, both signed by ISRG Root X1 and cross-signed by IdenTrust) didn't have this extension.
Following up the recent threads about this latest key ceremony[1, 2], I came across a link to the related GitHub page: Let's Encrypt 2020 Hierarchy. Here you can find a link to the Boulder's ceremony tooling used to generate the intermediates. In this README, we can see the following text currently:
Note: Intermediate certificates always include the extended key usages id-kp-serverAuth as required by 7.1.2.2.g of the CABF Baseline Requirements. Since we also include id-kp-clientAuth in end-entity certificates in boulder we also include it in intermediates, if this changes we may remove this inclusion.
7.1.2.2.g of the CA/B Forum BR 1.7.2 (current version) reads:
extkeyUsage (optional/required)
For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical2.For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kpcodeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.
For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent usages (e.g. including idkp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).2 While RFC 5280, Section 4.2.1.12, notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of subordinate certificates, as implemented by a number of Application Software Suppliers.
Personally, I think the BR isn't very clear about the definition for "Subordinate CA" and related definitions:
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Certification Authority: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
Personally, I think the distinct use of "Root CA" and "Subordinate CA" is that a subordinate CA is an organization without a root certificate present in Application Software Suppliers (i.e., browsers et c.). ISRG/Let's Encrypt wouldn't be such an organization, as the ISRG Root is present in Application Software Suppliers. Thus, ISRG/LE would qualify as a root CA, not a subordinate CA.
This is exact the opposite as what Mozilla describes in the link from @_az's post:
The term "subordinate CA" in this section refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates.
Skimming the BR it seems their definition of subordinate CA is as Mozilla writes: not as such a separate organization, but it's also possible to to read "Subordinate CA" loosly as "intermediate certificate issuing CA", even if it's the same organization. For example, section 6.1.1.1 writes:
For Root CA Key Pairs that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: (…)
There it apparently needs to describe exactly my definition of "Subordinate CA" by adding all those constraints..
The addition of most of the current text to section 7.1.2.2.g was adopted in Ballot SC31, corresponding with version 1.7.1 of the BR. To be exact, it was a commit on the git version of the draft ballot by sleevi on June 17th.
Personally, I think that ballot is close to a disaster. As far as I know, the idea behind the CA/Browser Forum is to make a default set of rules for everybody. If browsers start doing some weird stuff, you can't just incorporate those things in the BR and force them to everybody. In any case it doesn't make things more clearly IMHO.. This particular apparently was added due to the Microsoft Root Program.
I concur. The addition of "(…) with a Root Certificate (…)" makes this cross-signed intermediate certificate invalid. However, I don't know if this was wat sleevi intended? The previous 7.1.2.2.g didn't mention this at all. Also, the explanation about this modification to 7.1.2.2.g about the Microsoft Root Program (see link to PR above) doesn't mention this also. If we look closer to the Microsoft Root Program Requirements, currently we read the following applicable section:
- Issuing CA certificates that chain to a participating Root CA must be constrained to a single EKU (e.g., separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case.
I'm unable to link to the github page with history of that section, as the link to the github page (see the four grey dots at the top of the Program Requirements page @ MS) is dead unfortunately.
In any case, the MS Program Requirements don't make any difference between cross-signed intermediates or normal intermediates. So that makes the discussion about what sleevi intended and where he/she got it from about the Root Certificate exclusion of the cross-sign rule a little bit mute 
Pinging @jsha for this interesting discussion.
Back in the day, the BR didn't mention this, the SC31 ballot was adopted recently.
1: Let's Encrypt new hierarchy plans
2: Detailed 2020 hierarchy