Yea the 3DGS networking system is not suited for large amounts of players. You can indeed work around it (and I have), but it is really inflexible and unintuitive, error prone, etc..

So that's why I'm working on a networking plugin. It uses RakNet as the base and builds some functionality on top of it. The main functionality is done now: connecing to any number of servers/peers and inter-server connections, sending of packets which trigger event functions (events can be set per-packet type by the user), compression, encryption and client management. I have used unit-testing so it should be relatively bug free. I'm working on the plugin-interface now and it should be done pretty soon (if I don't become too busy again..).

It's good to see that the article mentions alot of things that I've come up with myself. For example the LCT, only sending updates to nearby players, and the giving higher priority to players nearby (although I haven't implemented that).

The use of a grid to calculate the distance is also an interesting optimization. To calculate the grid-square of a player, you could use a simple formula like:
square_x = (player.x + half_world_size) / square_size_x;

You could then store a pointer to that player in a 2D-array at that x and y position. To get the list of players that you are close to, you could just use the pointers in that array of all cells that are around you. No square-roots or scan()s.