Let us talk time budgets.
First of all, the rate at which the server sends updates, and the rate at which the client renders don't have to match. Many games will send updates less frequently than the client renders.
With that said, the server will have some time to get the input, simulate and send the updates. Let us say, a 1/60 of a second.
Getting input should not take long. The system will queue network input, and at the start of the cycle the server just takes whatever is in there.
Simulation will take some time. It might depend on the number of players. However, depending on the kind of game, there could be a remarkable amount of work that the server will do in simulation regardless of the number of players (physics and AI).
And finally the server sends the updates, which takes some time that grows linearly with the number of clients. However, hopefully these take little CPU time, as they are only sending data that was updated in the simulation, and the actual sending can be done asynchronously (and taking advantage of DMA).
So, you have time budget. Say 1/60 of a second. And you got to expend it in doing these things. Perhaps you don't use it all. If there is some wiggle room, you could take more players without a drop in performance. Otherwise, getting more players could mean allocating less time for simulation. And of course, you can get more powerful hardware.
Where is your bottleneck, exactly? It could be the CPU time, which is what I'm talking about above… Or it could be transference rate ("bandwidth"). Your network connection will cap your transference rate. If this is the bottleneck, then another option is to send less information to each player.
Some games will send less information in highly populated areas. For example, you get your full move set in instances, but in hub areas your movement is restricted (not using weapons, not running, and so on). This allows for simpler updates in hub areas.
Also, as you know, there is no point in sending updates about everything in the game, only about nearby objects and high priority updates. Since the client may stop receiving updates about an object for a while, eventually it is cheaper to send the whole state of the object than sending all the updates since the client last recieved.
I'll remind you that it is better to use UDP and build your own reliability models than using TCP. You don't want the server waiting on acknowledge packages, and you don't want acknowledge packages eating transference rate. Much less if what you are sending all the time are updates, you don't have to worry about a missed update if the next update overwrites it.
I also want to mention threading. It is possible to have a thread dedicated to the network connection for each client. In fact, this is the natural way with some network APIs. That means you could send data to multiple clients in parallel (limited by the number of cores on your machine, of course).
Finally, I have read that it is possible to use multicast in some scenarios (I have no experience implementing this). The idea is that the clients and the server would join a multicast group (done by telling the router), which will have a multicast address, and then the server will send to that address. The routers that support multicast will replicate the messages on the network.
