I didn't test it but I'm pretty sure it would improve the network time. You won't need to open an output stream on the socket to write a string and to open an input stream on the socket to read a string. It would improve both CPU and network time. You could write a small unit test to test out the time sending and receiving a string by streams and another test for the time sending deserialized object and receiving the byte array.

any packets that are smaller sized than the maximum packet size won't have an effect on throughput or latency at all
think of packetsize in GPU terms, if you draw very little with the gpu, the gpu will spend a measurable time "working on working with" the data
all packets that are <= the max size of the what the links on the route allows, will pass through intact
using as big as possible packetsize, but <= the correct packet size gives you the best throughput
for windows a MTU (frame) defaults to 1500 bytes (i think) over broadband, but that does not affect TCP packet size!
i imagine that tcp packetsize is at least 8kb, perhaps 16kb by now
i don't think you will be sending anything close to 8kb of data in one go, and it will most likely be alot less than the MTU size
in short: wether or not you use string stream, bit stream or serialized objects, it doesn't matter
java is a long-standing framework for JVM that most likely sends any kind of data just as effective as another

what really matters is how fast you try to send the tcp packets, and that they don't get split up (doubling the queue)
edit: and don't disable nagle
if you need the data to pass through immediately, use UDP, but it's not a recommended protocol
many firewalls block it.. among other things, UDP doesn't guarantee the order of packages arrive in the same order it was sent