Hey SOL..
To answer your questions:
1. Sending x,y angle, UID, and name every game tick is fine for a LAN game. Other than that, it causes too much network traffic for internet clients that don't support lots of bandwidth. There are a couple of solutions:
a. Send updates less often and then use a lerp to smooth movement. I show a simple example of this (lerp) in the netshooter .cap. Either way, over the internet with more than a couple clients..definitely need to send data less often. Valve's engines send updates every 3-4 frames and interpolate (lerp) to smooth the difference.
b. Use the RoundTripTime expression combined with player's speed/angle to "predict" their path/location. For example, send a packet that says "player 1 pressed the up arrow at angle X w/ velocity Y". Knowing that you can predict how fast he will be traveling and path is will take without ever getting new updates (i.e. if you know the player is traveling in a straight line then it makes no sense to send updates every tick for a path along that line). Having the RoundTripTime you will know what the lag is and can compensate (took 100 ms for packet to get to you so player is already moved further along that initially. If the remote peer takes their hand off of the up button then you immediately get that message and can predict based again on lag where the player stopped. Every few ticks the server can send the TRUTH out to everybody and everyone will get synchronized again. CAUTION: prediction does have it's shortfalls with games where movement can change rapidly so you have to send out the truth synchronization more frequently
c. Combine sends together vs sending lots of little ones out at a time..not sure if this applies in your case. However, try not to let your packets get bigger than MTU (1500 bytes).
d. Reduce the size of the packets through serialization. * This is not implemented in the plugin currently so I should be able to reduce bandwidth consumption by about 25% or so. Only problem with this method is that the way network data is constructed must change. Instead of being able to do a: playernum & : & angle &... I would have to define parameters that you would add like: param1 = int with playernum....kinda like the function object. This is a massive change to the plugin and I probably would fork the source and build up a new version.
2. Laggyness building over time. I'm not sure if it is a memory leak in the plugin as the core library ENET supports games with hundreds of players. Here is my guess with what is happening...you are sending out packets every tick..at first clients are able to handle things ok, but after a while packets start stacking up, ENET's automatic load handling takes over and starts dropping unrealiable packets (your x,y position packets) to help guarantee the reliable ones make it through. The more packets stack up the more that ENET will drop to maintain bandwidth levels.
Try doing an experiment and only send data once every 5 game ticks. See if the laggyness increases the same over time.