Your example looks quite badly indented, actually. And I find the colors (insert fancy word for "ugly" here). The contrasting rendering of the letters is distracting and makes the code harder to follow. The extra dark letters have strokes that bleed together, making them harder to read, the "m" looking mostly like a rectangular smudge, the "y" like some sloppy triangle, the square brackets looking at first like vertical bars. The light blue and green are indistinguishable (it wasn't until the fourth viewing that I even noticed that there was more than one cool pastel text color) and look rather washed out against the tinted background.
And that didn't even include any misapplications of "syntax highlighting" (at least that I noticed).
I'd be quite shocked if stackoverflow is automatically re-indenting code posted there (as you seemed to claim in your root node). I certainly don't want the code I post here re-indented and I certainly don't want to see some indenting other than that done by the author unless I am able to toggle such drastic rewriting (with the default being that such rewriting is not done).
I wouldn't be surprised if stackoverflow was using some low-impact, language-agnostic, common-keyword-recognizing, common-quoting-scheme-recognizing, "syntax highlighting". In fact, visiting stackoverflow (and taking quite a while to remember how to log in there) I find no evidence of it re-indenting my unindented code. And I find evidence of it using pretty much what I said in the first sentence of this paragraph. It was quite easy to come up with common Perl constructs that it highlighted incorrectly (// is assumed to start an end-of-line comment, for example). Most Perlish quoting is not properly handled.
At least the coloring at stackoverflow is so very subtle as to not be very distracting (and no use of bolding), but that is only appropriate as the very generic nature of the highlighting means that it can easily be wrong (depending on what language or non-language the blocked text actually contains -- certainly often wrong in the case of Perl code).
So I think you are quite mistaken in your original impression that many sites automatically re-indent code. My experience is that such an activity can so easily go astray that it wouldn't be long before such a feature were abanodoned (seriously changing the apparent meaning of code need only happen a very few times before such drastic attempts at enforced aesthetics lose favor, surely). I expect most who thoroughly consider the idea would at least be conerned about potential problems with it, especially for Perl code.
As for just adding some color to the contents of <code> tags at PerlMonks, I have plenty of experience with code being strangely (or "badly", depending on how charitable I want to be) written because writing the code more sanely illustrates a bug in some syntax highlighter. And I almost never use syntax highligting myself but I've still run into many such cases (and I never use it for Perl code and most of the bad examples are for Perl code).
There actually have been very rare times when I've found syntax highlighting helpful. They were always when I missed something small but drastic like an unclosed quotation or an unclosed comment (in SQL, FYI -- and SQL usually has really sucky error messages so the extra help is more appreciated there). But I find incorrectly highlighted code to be a much more serious problem than I find correctly color-coded code to be a help, especially for the high-impact things like the highlighter thinking way too much is quoted.
And I find giving vague color hints that are sometimes going to be incorrect hints to newbie Perl coders on a site like PerlMonks to be a pretty bad idea as well.
And I have yet to notice stackoverflow offering users a choice of color schemes and having quite a few users who have customized their own color scheme still further. So I doubt anybody could produce a code colorizer for PerlMonks that didn't produce ugly even unreadable results for quite a few members.
So any syntax highlighter one picks is going to get some things wrong for Perl code (which isn't the only thing put into CODE tags here, of course). So it should be up to the person who is choosing to use a syntax highlighter to pick one whose quirks don't outweigh its benefits to them. For me, my choice is "none". But many make other choices. If there is a syntax highlighter that you like, then arrange to use it in your client. We even supply tools to assist in such client customization. Running into bugs and quirks in a syntax highlighter that was forced upon you by some site admin surely quickly becomes very frustrating. Let's not go there.