In that context, reviewing code would be difficult, if not impossible, to do via email.
I'm guessing one disadvantage is the method of diff is hard-coded into the patch. It would be good to switch to word-diff, or ignore whitespace, but I'd imagine these could be applied as transformations on the generic format.
The plugin I use in Thunderbird can switch between unified, context, and side-by-side diff views based on the same email. Adding the transformations you mentioned could be done.
But one limitation that email has over other review tools is the lack of ability to expand the view of the context within the client. The only way I could think of is to have git format-patch generate the diff with the entire context included and then have the client limit the display of that context. But that not have a reasonable fallback for those using clients that aren't capable or configured to do that.
Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied. Should display just fine in GMail.
That won't work because people actually download those email messages and apply them to their local repository with the git am command and they also expect to be able to reply to the email inline when commenting on a patch. Also, for mail clients that don't support HTML rendering, it would be much more difficult to read or respond to an HTML email.