The point of SAMP is interoperability, and VOTable is the agreed exchange format.  If you use a different format, other applications won't understand you.  For what it's worth, a couple of reasons that VOTable was chosen is that it's good for transmitting metadata (unlike CSV and to a lesser extent FITS) and you can stream it (unlike FITS, in general, where you need the row count up front).

If you dislike large data streams you have a couple of options.  VOTable has a number of different serialization formats; `TABLEDATA` is the one with the `TR` and `TD` elements, but more compact alternatives are `BINARY` and `BINARY2` (though the latter may not be so good for interoperability, since it's a recent addition to the standard).  You can also use a FITS BINARY table wrapped up in, or referenced by, a small amount of VOTable XML.  Or you can gzip the stream at the HTTP level.

As far as serializing numbers to ASCII goes, the serialization format in VOTable is well-defined so although you may be experiencing issues, they are not inevitable.  If the implementation is doing it in a way which loses precision that ought not to get lost, that sounds like an implementation bug in the VOTable de/serialization code.