It's mainly to limit the speeds of craft in the game, as well as affect its handling during sharp turns.
Real-life space does indeed have a sort of drag coefficient, but it's very dependent on how much matter (a.k.a. junk) that's in the area the craft is trying to pass. The more matter, the greater the drag, the less matter, the less the drag.
There's also this theory out there that says a space craft can't go faster than what they eject out of their engines. This has a direct effect on the acceleration of the craft as it reaches its maximum velocity. This can be modeled as a drag coefficient
Drag would cause triple the math to be done for all moving objects on every tick (acceleration, drag, and movement), whereas 
's method only adds load when stuff is changing speed or direction.
Hmm, yes...
For simplification purposes, the space drag would be omitted, and only the terminal velocity drag would be used. (the space drag could be put in for a later date if needed)
Terminal velocity drag would only be applied to the craft when the player is change their speed or heading. (During glide, the calc's would be omitted.)
My whole point of asking about the acceleration is related to what the multiplayer code transmits.
I'm assuming, that the multiplayer code would transmit the coordinates, velocity vectors, desired velocity vectors, and time to achieve desired velocity over the net.
If the drag coefficients where to be a linear function of the ship's velocity, you could store them in a .tbl somewhere. You could then send over the position, velocity, and acceleration (9 values) and have the receiving computer interpolate the craft's movement until the next packet is received.
The question then would be, if the added math costs would be worth the bandwidth saved...
