That's irrelevant to the point in the parent that I was responding to - that every app uses tab to format text. Most apps don't. There are a limited section of apps that use tab for text formatting. I'm pretty sure most web browsers never have, although I welcome examples of web browsers that do.
If people want to write real email they can use a real client, not a web interface.
I think it's relevant. I expect app designers to use the keybindings that make sense based on what the user wants to do instead of blindly adopting whatever guidelines the OS suggests.
If you're in the shell, "tab" should tab-complete, not move to the next terminal you have open.
If you're in a shooting game, "tab" should reload your weapon or show scores or whatever, not advance your cursor to the next target.
If you're in MS word, tab should indent the next line, not move to a different control.
If you're writing an email, same thing, because "writing" is most like "writing in MS word."
Re: your second point, Gmail is a really good "real" web client, at least for most people, and this is a small step away from that.
None of your other examples have the conflict of running within a browser, and the browser already having an expected behaviour for tab, including an expected behaviour for tab inside a text box / edit field.
That's actually not an easy problem to solve. When I'm creating some (desktop) UI that has multiple controls one being a text box, it always destroys the workflow (tab - next, tab - next, tab - indent.. crap..). I did not find a good solution for this so far.
Edit: Thinking about it.. maybe I'll try big G's version.
Thus, when I hit [tab] now focus is taken out of this text box and to the reply button.