Coming back to
1 - specific monsters are on another "team" and attack other monsters/players who are not on that "team"

In the first post we've adjusted the rules for REACTION in combat so that our teams don't fight amongst themselves. But getting them to pro-actively attack the other team on their own initiative is another story. I see two big problems

Problem 1: In regular quake, the task of searching for a client who the monster might be able to see and ruling them out if they are in a part of the map not visible from the monster's position is entirely offloaded to the engine. The function is called "checkclient" and it does the whole thing in one go.

Because it's in the engine, your mod can't change how it functions. So you'd have to write something new from scratch in QuakeC to replace it. The engine has access to additional data that QuakeC can't get at, and it exploits some of that data in checkclient - so you can't even create an exact copy in QuakeC as a baseline. It's a very tall order.

Supposing you solve problem 1, problem 2 is a more practical one. You create your map full of rooms, each populated by squads of monsters from team A facing a squad from team B. The player spawns in, and your new AI kicks in. Across the map, team A fights with team B, even when the player is nowhere nearby. A victorious team emerges in each fight, and for the player the only evidence of all this groundbreaking AI is a pile of corpses from team A, and some half-health monsters from team B.

This is probably not what you had in mind - more likely you were wanting the player to be present each time the teams fight so they can see and engage in the spectacle.

That's why I would recommend you CHEAT instead. Rather than creating brilliant AI, just script the fights a bit. Have an entity who looks for monsters with a specific targetname, and assigns them an enemy with the same targetname from the other team. Make sure you trigger this entity when the player is approaching the battlefield. And when a monster kills a monster with the same targetname, make it retrigger to pick them another target. 

Also how can I edit ATTN_NONE ATTN_NORM ATTN_IDLE etc?

The good news is that while the values of
ATTN_NONE/ATTN_NORM/ATTN_IDLE/ATTN_STATIC make it look like there are just discrete values for attenuation, actually the final parameter to sound is a float, and you can supply any decimal starting at 0.0 and going up to (but not including) 4.0.

One of the confusing things is getting a handle on exactly how the scale works. It's actually a backwards scale - the higher the number, the smaller the distance that the sound travels. ATTN_NONE is the absence of attenuation, which means that the sound transmits across the entire level at full volume. If you still want a drop off, but slower than normal sounds, why not try a value of 0.5 instead of ATTN_NORM?

Tiny detail: ATTN_NORM and volume of 1.0 do have a magic benefit compared to other values, although it's a fairly minor one. They actually require less network bandwidth to transmit in a packet, because they are regarded as the "baseline" values, and the protocol only transmits variation from the baseline. In single player scenarios this doesn't make a difference, but it's an interesting quirk to note.