Yes, I think that’s a step in the right direction to put this data onchain.
This is true in isolation. However subresource integrity is enforced by browsers at the whole-page level (through the Content-Security-Policy header). So for the purpose of having the browser enforce the use of SRI, it is beneficial to require that dapps provide SRI hashes for all resources (including relative ones), despite this being technically redundant in the context of the IPFS bundle.
“What if the gateway is compromised and just strips the Content-Security-Policy HTTP header?” Valid objection. I still think the ability for gateways to set a strict Content-Security-Policy header is good defense-in-depth. It is also likely that browsers and CSP will extend SRI to make it more useful, for example by allowing CSP pinning on a per-domain basis.
Lastly, on a more practical level, ~all implementations of SRI I have seen in practice rely on automated website bundle generators which take care of SRI-ing everything, so requiring relative resources to be SRI’d doesn’t seem like a large additional burden to ask of dapps that would already need to provide such hashes for external resources. That said, I do agree that a reasonable carve-out might be something like “if the dapp is self-contained to its own bundle and has no external resources, it is not required to provide SRI hashes”.