As a developer who focuses on UX, I disagree, on the grounds that I believe that when editing code, TAB is expected by most users to create a tab, not jump to the next element in the page.
I agree! When I'm editing code in my development environment, I'd like tab to create indentation. (In my case, four spaces rather than a tab character.)
However, when I'm writing my post, I'm not in my development environment, and I'm not editing code: I'm writing a post for a website. I expect my text box to behave like a text box. I expect to be able to tab out of it. I also expect that my key bindings won't magically change because I've started a line with four spaces or written
<code> in my post - as a UX developer, you may recognise why this is not a great experience.
Now, my answer might contain code, but I don't expect to get any serious programming done in this editor I'm typing in anyway: I expect to get it done in Visual Studio, or Sublime Text, where I write my code before pasting it here. Also pertinent, in my case, is the fact my answers rarely contain code: the SE sites I use most frequently are ones that have nothing to do with programming, and even on Stack Overflow I'm more interested in theory-based questions and answers which contain little to no code (like these:
Now, donning my own UX hat...
I'm a user experience designer and web developer who's presently deeply involved in accessibility and helping a site conform with W3C's Web Content Accessibility Guidelines 2.0. This means my job is about making sure those who are blind, have limited mobility, or so on can use the site effectively and have a great user experience.
A large portion of this concerns blind or visually impaired users who rely on a screen reader and keyboard controls to read and get around a page. Hijacking the tab key is one of the best ways to make that difficult or impossible for them, especially within a form control. Doing this is called a keyboard trap. A user who doesn't know the proper hotkeys to get out of a keyboard trap may need to simply reload the page and hope not to run into it again. This is a big concern when the keyboard trap in question is one of the most heavily used features on the site: the text box for writing and editing questions and answers, in its various incarnations.
This is a big deal, and one of the WCAG success criteria is aptly titled: No Keyboard Trap. It requires you to make special provisions if you create an element that "requires more than unmodified arrow or tab keys or other standard exit methods" to get out of. It's better to not be in that situation in the first place.
For the rest of us, we can go do our serious code editing in a serious code editor.