Why does TCP cost more on a memory-constrained device?

Because TCP is stateful per connection, and that state lives in RAM. Each open TCP connection needs a send buffer and a receive buffer (sized for the window, which affects throughput), a retransmission queue holding unacknowledged data until it's confirmed, and connection control state (sequence numbers, window sizes, timers, the state-machine status). On a desktop with gigabytes this is invisible, but on an MCU with a few kilobytes to tens of kilobytes of RAM, each connection can consume a meaningful chunk, so a small device can sustain only a handful of simultaneous TCP connections, and the buffer sizes directly trade off against throughput. The handshake also adds round-trip latency before any data flows and, on a battery-powered radio device, energy. This is a core reason embedded designs minimize the number of TCP connections (often a single persistent connection to a broker, reused for everything), tune the stack's buffer counts and window sizes to the available RAM, and sometimes choose UDP-based protocols (CoAP) whose per-datagram footprint and lack of connection state fit constrained budgets far better. So "TCP costs more" is concretely about per-connection buffers, retransmit queues, and control state in scarce RAM, plus handshake latency/energy.