Well, if an attacker can gain access to the system and modify files at will, he can also just modify hashes.json or modify the code to whitelist the modified files - that doesn't really add much protection 
That said, I agree that a whitelist isn't a that great idea but I can also understand the desire to have such a feature.
It's pretty much the same for any kind of logs and why we have tools like logcheck and it's ignore rules.
As far as optimized resources are concerned:
This can be dealt with by using clever server configuration - store the optimized resources in another place (add a suffix, use another directory, etc.) and point the server there (via alias, try_files, rewrite, etc.).
This way you can easily serve optimized resources while not touching the original files.
Btw: Compressing Add-on icons (eg. images referenced from addon.json) is really unnecessary - those are being served inline as base64 in backend only; do you care for those being optimized?
If you really do, even that would be possible with by extending \XF\AddOn\AddOn::getIconUri().
The whole src directory is set as deny from all via .htacess, so with a default setup nothing can be served from there directly.
And if Add-ons are servering resources from there, they are IMHO badly coded and must be fixed - resources should go to js and styles.
Therfore, I personally would not bother with src at all.
Doing this would cut down the modified files from the screenshot significantly.
The modified files from the screenshot are extendable classes, so I'd just write extensions for them to add the required changes.
