The view of the exterior has to be carefully controlled. I'll explain in more detail below and explain how I optimized parts of the map.
According to the mapping guide, the max wpoly limit should be 700. However, I think it is a mistake to set a fixed number, and some of the maps in ns exceed 900. Instead, it's best to think of a poly limit as a budget. Sometimes it is worth paying a little more for a better product, and sometimes products are simply overpriced. If you work efficiently, you should get good value for the price. The emphasis should not be on a fixed number, but rather on value vs. cost.
Here’s a picture of the exterior while looking up close at the window in communications:

The poly count isn’t bad for the view. However, when you step back a bit:

Even though the player doesn’t see it all, the engine still renders it. Originally, if you stood in the middle of the room, it maxed out at about 1000. To fix that up a little, I added the wall as a vis block. The r_speeds still max out at about 800 when you’re by the window, but they drop like a rock in the rest of the room, which is where most of the action will be.

Forgive the rough look of the vis blocking wall. It wasn’t done at the time I took the picture. However, you can see that by the node, the r_speeds drop to about 500, and if you stand behind the vis wall, in the center of the room, it’ll drop even more. Therefore, the view does deviate a little from the 700 limit, but it’s contained to a small area of the room that won’t see as much action.
In the top right corner, you can also see how I lit the monitors. At 128 x 256, an overlay would chew up more texture memory. Instead, I used a func_illusion that faces the screen rather than the room, and set the render mode to texture and render amount to zero. Then, I used the eyedropper tool in Photoshop to get the most common color in the monitor texture, and used that for the light texture, which is only 16 x 16, in the rad file. However, I've since replaced the func_illusions with entity lighting to lower leaves.
All the windows in the core bridges used to be open, and like Communications before the vis block, the r_speeds maxed out at about 1000. I fixed it by closing some of the windows, which lowered it to about 500.
Here is a picture of the pipe in waste:

In the red circle, you can see brush fragmentation that’s caused by grouping multiple brushes into one entity. In the green circle, you can see faces repeating because the texture scale isn’t high enough. Because there are so many faces on the cylinders, this gets costly.
To optimize it, I scaled up the texture so that it does not repeat. Simply divide the length by the chop size, which is 240, to find the minimum texture scale that will solve this. Next, I used a separate entity for each cylinder to prevent the brush fragmentation, and since the cylinders are entities, I used null on the ends so that they are not rendered.
Here’s a picture of the optimized pipe:

func_seethroughs on the top of the service tunnels would be like Communications and the core bridges before optimization. It would probably hit 1000.