Zireael, that isn’t what he means at all.
Think of it this way. In Eternal Battlegrounds, there are the following objectives: 1 jumping puzzle, 3 NPC camps, 9 control points, 6 camps, 12 towers, 3 keeps, and Stonemist. So, lets actually assume players are distributed equally (and not in a giant zerg) and just make up some numbers to see the dilemma ANet is facing.
We have Jumping Puzzle (5 players), 3 NPC camps (5 players x3 = 15), 9 control points -or- supply support (3 players x 9 =18), 6 Supply Camps (5 players x 6 = 30 players), 12 towers (10 players x 12 = 120), 3 keeps (20 players x 3 = 60), and Stonemist (30 players). That gives us a grand total of 278 players from the server across the map.
Now, assuming they square off against an exactly balanced force, the server has to track (IE: location, health, abilities, etc) all nearby players. So, it must send data about every player in the vicinity to all players in the vicinity. It must check incoming damage against every nearby player. (This is the N squared problem that was mentioned by Habib; you can see it below in the format: n*n * node_count = n^2 * node_count).
Lets run the numbers: Jumping Puzzle (5×5 = 25), 3 NPC camps (5×5×3 = 75), 9 control points -or- supply support (3×3x 9 =81), 6 Supply Camps (5×5x 6 = 150), 12 towers (10×10x 12 = 1200), 3 keeps (20×20x 3 = 1200), and Stonemist (30×30=900). That gives us a total of 3631 relevant changes that need to go out by the server.
Now, what if we have one massive zerg of 250 v 250? That’s 250×250 relevant changes. That gives 62500 relevant changes that have to be sent by the server. What if there are simply 5 groups of 50×50? That’s 12500 relevant changes that have to go out. What about 8 groups of 30×30? That’s 7200. How about 12 groups of 20×20? That’s 4800. What about 16 groups of 15×15? That’s 3600.
Do you see the problem? The server load isn’t constant. It depends on the distribution of players. Increasing player count (decreasing queues) introduces the potential for lag if players clump. Decreasing lag if players clump means reducing player count (increasing queues). This conflict can never be resolved. There is a conflict here that can never be resolved while both lag and queues exist.
TLDR: More players come at the cost of potential lag during zerging. Lag reductions come at the cost of players allowed entry. Which do you chose? ANet has striven for a balance with a bit of a focus on players over lag. Their hope is that there won’t be a massive zerg because it is so brutal on their server. I think they chose correctly. I also applaud Habib for being straightforward about the issue.
Player culling optimizations are a different subject; one that ANet is looking into.