Why stream
A non-streaming Messages call blocks until the entire response is generated. For long completions, that is several seconds of dead UX. Streaming returns Server-Sent Events as the model produces tokens, dropping perceived latency to time-to-first-token instead of time-to-last-token.
The event types you actually handle
The SDK abstracts the SSE wire format into typed events. The five worth knowing on day one: message_start (initial response shell), content_block_start (a new text or tool block begins), content_block_delta (incremental text), content_block_stop (the block closes), message_stop (the response is complete). Tool use streams as a separate block type with its own delta shape.
Streaming is harder than it looks
Disconnects in the middle of a stream leave you with partial output and no automatic retry. Token counts only finalize at message_stop. Tool-use blocks need to be reassembled from deltas before you can parse them. Streaming gives the user faster feedback at the cost of more application code.