May be a bit too late to ask …
If we’re trying to squeeze out every last bit, why do new intermediates have this:
X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication
Are you actually using them to authenticate boulder servers to each other in addition to CA signing?
Have you considered creating R intermediates with 3072-bit RSA/SHA-384 to align with compliance requirements of global cryptographic authorities (e.g. CNSA Suite, and others)?
E is fully compliant - its 384-bit ECDSA key is equivalent to 7680-bit RSA and equivalent to symmetric strength of 192-bits (e.g. AES-192).
2048-bit RSA is currently the bare acceptable minimum (NIST SP800-131A Rev.2), who knows if it will hold over the 5 years life span of these intermediate keys.
2048-bit RSA is equivalent to symmetric strength of 112-bits which is less than strength of AES-128 and less than SHA-256 that everyone is using in ephemeral ciphers nowadays.
Already in 2016 there were lengthy debates about making 3072-bit keys subscriber certs default for Certbot (see the still open Issue 2080) - a bit pointless if the CA signing them is 2048-bits.
These CA certs unlike the subscriber certs that last 90-days, or even the latest 13 months maximum limit - they need to hold the fort for 5 years.
The strength between R and E intermediates is really skewed, and these R intermediates are the cryptographic weakest link.
Was it decided that for anyone that needs to be compliant, or is security conscious, E cert chain would be their only option?