You only need about 30 updates (or even less maybe 10 or 20) per second. interpolate the positions of moving objectts client sided.
In general you should only send data when it's REALLY needed.
In WoW you might receive more updates from the players you are in a group with than from the players that are in the same location.
Also, if another player is far away from you, you don't receive as many updates per second about him.
Then, only send one complete snapshot to each player when he connects. After that only send the changes of game objects. If no change occured, don't send it.
Then, make heavy use of BitVectors or howevery you might call them to reduce the amount of unneeded data! Example: You can also try to write a float using only one byte(in a range from 0 to 1 or -1 to 1) so you only have 256 or 128 different values. But the player will not notice any jerky movements thanks to the interpolations.
Look at this for an example with LidgrenLibrary on how to compress data: http://code.google.com/p/lidgren-network-gen3/wiki/Optimization
Next: Try to reduce view radius of players as they move, and only transmit important information in that time. Then when they stop increase their view radius again. You can use a spatial hashing system or a bsp tree to reduce the overhead of looking up objects that are "in range".
This is a good read for the topic: http://en.wikipedia.org/wiki/Collision_detection
Also compress the data YOURSELF only YOU know about the data structure and the temporal coherence in the data (which can and should be exploited).
A general algorithm such as Bzip2, Deflate, whatever, should be used, but only as the final stage of compression!
Also, for non game-critical information, you could also employ additional P2P techniques.
Example: A player plays the "hello" animation.(Just a graphical effect) The player sends this information to the server, but the server doesn't relay the information to the other players. Instead this non-critical effect is send by the player itself to the other clients in range.
EDIT (because of the comment):
Additional methods to decrease the average bit count per second to each player:
You wrote that you send "Object did not change". There is no reason to do this.
If you worry about packet loss (and getting your simulation out of sync because of this) consider the following:
At each fixed timestep (ex. 100, 200, 300, 400...) hash the simulation state and send it to the server. the server confirms or sends a complete snapshot of all data back.
For things like rockets or even players you can employ not only interpolation but also extrapolation in order to make the simulation more realistic.
Example 'Rocket': Instead of updating with messages like "Is now at position x" just send a message once containing the following: "Rocket Spawned: position(vector), Time(at which simulation step the rocket was spawned), velocity(vector)".
So you don't even have to include the rotation because the tip will always be in the "velocity" direction.
Combine multiple commands in one message and don't ever send messages smaller than 16-20bytes because the udp header will be bigger than the message itself.
Also don't send packages bigger than the MTU of your protocol because fragmentation will slow down the speed of the transmission.