Normally, once the TLS handshake is complete, the client and server can exchange encrypted traffic on the same connection without having to communicate the session id. This is because the server associates the SSL context information (including the session key) with the TCP socket on its end. You can see this in this simplified example of a TCP server: https://wiki.openssl.org/index.php/Simple_TLS_Server
However, there are two scenarios where the session id is communicated after the initial handshake - session resumption and session renegotiation.
Session resumption allows the same TLS session (containing all the parameters agreed in the handshake) on a new TCP connection after closing the original one. This means the connection could time out, and your browser would detect this case and resume the TLS session on a new connection by sending the session id in a new Client Hello. More details on session resumption here: http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
Session renegotiation is used to change the parameters to be different from the initial handshake, but on the same TCP connection.
As you mention, the storage of a session cache on the server compromises security. An attacker could gain access to the session cache and then decrypt traffic. More details on this here - https://blog.compass-security.com/2017/06/about-tls-perfect-forward-secrecy-and-session-resumption/