Why is "TCP is a byte stream" a common source of bugs?

Because TCP does not preserve message boundaries, it guarantees the bytes arrive in order and intact, but not that they arrive grouped the way you sent them. If you call send three times with 10 bytes each, the receiver might get all 30 in one recv, or 5 then 25, or any split, because TCP is free to coalesce or segment data based on buffering, the path MTU, and Nagle's algorithm. Application code that assumes "one send equals one recv" will mis-parse: it reads a partial message, or two messages glued together, and corrupts its protocol state. The fix is to frame your own messages on top of the stream, prefix each message with a length, or use a delimiter, and have the receiver accumulate bytes until it has a complete message before parsing. This is one of the most common mistakes when people first write TCP applications, and it's invisible on a fast local link (where sends often happen to arrive whole) but breaks in the field under real network conditions. UDP, by contrast, preserves boundaries (each datagram is one recv), which is sometimes a reason to choose it.