As https://trac.nginx.org/nginx/ticket/621 explain, this message is harmless. It won't cause errors for visitors. Instead, affected returning visitors would take a small efficiency penalty from not having SSL session resumption.
You could modify /etc/letsencrypt/options-ssl-nginx.conf and alter the following lines (bigger cache, or lower timeout, or both):
and then reload nginx. But keep in mind if you change this file, then Certbot won't apply automatic updates to it anymore. You'll have to keep it up to date manually.
Tuning these is tricky; there don't seem to be any concrete answers for "what values should I use when I get x SSL clients per day?". There seem to be some performance and security implications either way. To further complicate things, TLS 1.2 and TLS 1.3 differ with this specific configuration (session ID resumption only for the former, stateful tickets for the latter).
Aren't the security issues just that session resumption makes it easier for a network adversary to identify users (in TLS 1.2), easier for the web server operator to recognize users even without cookies or device fingerprinting (in both TLS 1.2 and 1.3) and effectively a less aggressive session key expiry for forward secrecy properties (maybe in both or maybe just in TLS 1.2)?
If so, I'd say most sites and most users haven't worked out a threat model that's explicit enough to clearly justify worrying much about this, unfortunately.