The “stack” described [1] can not transmit a payload stream. That also means it avoids the “costly (in terms of lines)” problems of transmit flow control and “reliable send” guarantees in the presence of transmit pipelining needed for even modest throughput. For that matter, it does not even reconstruct the receive stream which is, again, one of the more “costly” elements due to data allocation and gap detection. It also does not appear to handle receive side flow control either, but that could be hidden in the TCP receive engine state which is not described.
These are not minor missing features. The thing described does not bear any resemblance to a actual TCP implementation, instead being more similar to just the receive half of a bespoke stateful UDP protocol.
Now it is possible that the rest of the TCP/IP stack exists in the other lines, as only about 25-ish lines are written down, but you can conclude almost nothing from the described example. The equivalent C code supporting the same features would be similar-ish (under 100 lines) in length, not 10,000 lines. That is not to say it is not a tight implementation of the feature set, but it is not reasonable to use it as evidence of multiple order of magnitude improvements due to representation superiority.
[1] https://worrydream.com/refs/Kay_2007_-_STEPS_2007_Progress_R... Page 44