Yes, red/blue is kinda default .. but conventions do have their benefits - I'd rather blame Sauerbraten for the somewhat confusing method of skinning members of the opposing team always in red .. since this approach (which has it's pro-arguments too, I know and even agree with it in general) does have the down-side of making it impossible to skin the bases/sides toward the same color-scheme.
But you're suggestion of magenta VS green might work as an acceptable alternative .. going for a white light texture and doing some form of

// colored lights

setpixelparam 0 .5 1 .5
texture 0 lunaran/light_ceil1_d.jpg
texture n lunaran/light_ceil1_local.jpg
texture g lunaran/light_ceil1_g.jpg
texture z lunaran/light_ceil1_h.jpg

(taken from packages/base/metl4.cfg)

RE "defensive" - well it was more of a first impression really, after re-checking I don't think it's gonna be that "bad" (although I don't think the concept wouldn't work) - the two levels give opponents enough chance to break through .. yet if you'd imagine there only being one level that cross-over section would be pretty easy to defend, very hard to break through .. that's what I was referring to with "defensive tactics" .. as long as you maintained a good defense your flag would be safe and it would require superb teamwork (coordination) to get through any break in your opponents defenses - not so many captures, but .. if done right .. might be a map for high-class fighting, probably too frustrating for public matches ;-)

Opponents always red, confusing? Not at all! In fact, I wish more games did this. It'd eliminate all the "wait, which guys do I shoot again?" moments.

Of course, it does mean you can't color-code the bases...
Hmm.
It probably wouldn't work to do some if-thens in the CFG to load textures based on team. (Even if it did, the player could change teams, and then it'd be backwards... But maybe check if the team has changed every second or so?)

Well - it seems to confuse a lot of people, that's why I felt safe stating it like that ...
... but since I know (and agree with the other side of the argument) I included the bracket-bit to soften it - but you just couldn't resist SheeEttin, eh? ;-)
In the end there are points on both sides of the argument.
RE: team-textures ... well, how about having internal variables for team-colours that could somehow be implied by the mapper .. make a light entity have attr5 set to 1 or 2 to make it for one or the other team and then those bits of the lightmap would get coloured in two magic-number values and those magic-numbers translated back to colouring as to the players specifications ... there ARE ways - just not stuff that doesn't come with a lot of coder's sweat into the bargain .. even though I can name the path one could take, I wouldn't dare assume I can make it happen!

I'd even suggest something like this for those of us without shaders:

setshader bumpparallaxglowworld

setpixelparam 0 1 0 0
texture 0 "<mad:1.0/0.0/0.0>lunaran/light_ceil1_d.jpg"
texture n "lunaran/light_ceil1_local.jpg"
texture g "lunaran/light_ceil1_g.jpg"
texture z "lunaran/light_ceil1_h.jpg"