The bottleneck is almost certainly the upload rate on the host. Our multiplayer plugin imposes no specific limit, but due to connection limits the service will seriously degrade after a certain point (which will depend on the connection).
The problem is the host has to send data for N players, to each of the N players. So if each player needs say 10 bytes of data, then each message will have a size around N * 10, and then that message will have to be sent N times. This creates an N^2 bandwidth requirement. For example:
10 players = 10 * 10 * 10 = 1000 bytes per update
20 players = 10 * 20 * 20 = 4000 bytes per update
30 players = 10 * 30 * 30 = 9000 bytes per update
...
100 players = 100,000 bytes per update
As you can see even though the player count increases linearly, the bandwidth requirement increases proportional to the square. This means even with a significantly more powerful server or a much more compact update, it won't get you many extra players.
The engine sends updates 30 times/sec by default, so the last case takes 3mb/sec up. Note then also that if the server has a 5mb/sec up capacity, then it will take 600 ms to send 3mb of data. This adds latency to every player. The game would likely become unplayable long before it was adding an extra 600ms of latency.
So not only do you need lots of bandwidth for lots of players, to keep it responsive you need to significantly over-provision the bandwidth - say, by 10x.
It's possible to make very large games with spread-out players able to send data only for nearby players (e.g. MMORPGs). This is one workaround which we might look in to with our engine.