I have little hope that this workaround works in Let's Encrypt case, as Sectigos chains were different back then (they also had problems with expired intermediates, lots of cross signs all over the place).
I just tested with the oldest OpenSSL I had lying around (simulating that DST Root CA X3 has been manually removed from the trust store):
# openssl version
OpenSSL 1.0.1j 15 Oct 2014
# openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -CAfile letsencrypt-stg-root-x1.pem
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify error:num=20:unable to get local issuer certificate
verify return:0
140518814185152:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1930:
Note that on these old versions you need to use -CAfile instead of the -verifyCAfile I used in my other examples.
What happens here is that without DST Root CA X3, OpenSSL cannot build a chain at all. We tell it to validate with ISRG Root X1, but it doesn't work, as the server chain never contains ISRG Root X1 as root, only as intermediate. These old pre-1.1 versions apparently do not allow partial chains, so it always wants to validate up to DST Root CA X3 (unless TRUSTED_FIRST is present, which has already been discussed). If DST Root CA X3 is in the trust store, it fails because it's expired. If not, it fails because it can't find it.
Someone with CentOS 7 + OpenSSL 1.0.2 needs to verify if the same applies on that version, as my test above is even older than 1.0.2. I currently don't have a 1.0.2 version at hand, but I believe they behave similar.