You shouldn't set "trim_trailing_white_space_on_save": true unless you work alone, otherwise you're going to have random whitespace changes polluting your diffs.
On the occasion where whitespace does pollute the diff, GitHub has a convenient feature where you can append '?w=1' to any diff URL and whitespace changes will be omitted.
What are the arguments for having whitespace removal as a coding standard?
Having the editor just trim those automatically is just delegating the trailing whitespace care to a piece of software with a simple rule: no whitespace allowed.
If the entire team working on a project agrees to this rule, everything's peachy, and it's really easy to convert an existing repo to it - whenever you touch a file, if there are whitespace changes, commit them to a separate commit.
At the end of the day, it's just standard, so doing invasive changes to a project that doesn't follow that standard (as in the pull reqs you descibed) is wrong, but that doesn't mean the rule itself is bad.
As for ST2, it allows easy per-project settings so you can easily enable it globally and disable on a specific project if needed (or vice versa).
git diff --ignore-space-at-eolIdeally whitespace would be trimmed from lines that have otherwise changed, thus ensuring a gradual (though probably never completing) repair of the code.
There's no reason to use shitty tools here.
It can:
git merge -X ignore-space-at-eolHalf the time the pointless whitespace is introduced by an editor that auto-indents for you.