This strategy can also conceivably help defend against automated attacks. Many bots alter well-known files in well-known locations, especially when popular CMSs are involved, and do not necessarily touch anything else on the server, which would require knowledge of the local paths and setup — and heighten the chances of being discovered. For example, if a vulnerability were to affect a well-known WordPress theme, which is not unheard of, I can imagine an attack bot using the exploit to booby-trap a JavaScript library that is known to be part of the theme (something long and dense and boring like a minified jQuery file), without altering anything else. The internal SRI check would defend against this.