Streamable HTTP supports both stateful and stateless servers. The protocol does not pick for you; you choose at design time and signal it with the Mcp-Session-Id header.
A stateful server issues a session id during initialize (Mcp-Session-Id in the response). Subsequent requests carry the same id back in the request header. The server uses the id to look up per-session state — open subscriptions, paginated cursor positions, in-flight long-running tasks. Tear-down is explicit: the client sends an HTTP DELETE to the endpoint with the session id when it is done, and the server reaps the state.
A stateless server does not issue a session id. Every request is independent; per-call work is done in-process and discarded. Stateless servers scale horizontally with no coordination — any node behind a load balancer can serve any request — but they cannot offer subscriptions, cursored pagination across calls, or any feature that needs to remember "what did I last say to this client?"
The choice is operational. Stateful servers are easier to write but harder to scale (you need sticky routing or shared session storage). Stateless servers are easier to scale but force you to push state into the request payload (e.g. cursors as opaque tokens). Most production deployments end up stateless behind a CDN-like edge with state shared via Redis or similar — that gives the simplicity of stateless plumbing and the capability of stateful semantics.