Just a thought, but some of the big corps try to scale down TLS handshakes by having widespread TLS resumption support. The resumption TLS handshake cuts down on resources quite a bit, namely by skipping all the asymmetric crypto*.
TLSv1.2 supported two mechanisms (session ID + session tickets) for this. Session IDs were okay security-wise, but difficult to distribute across instances in a load-balanced/distributed server environment. TLSv1.2 session tickets could be synchronized across servers if they all shared a single secret, but had pretty bad security properties. TLSv1.3 built upon the session ticket approach, but replaced it with a PSK-as-a-ticket system that also supported PFS, so overall is much better. The secrets used to generate the PSKs server-side can also be shared across multiple instances in a distributed system (very similar to how TLSv1.2 did it).
According to basic TLS debugging tools, your Traefik instances already do TLSv1.2 session tickets + TLSv1.3 PSK resumption handshakes, with an advertised max lifetime of one week (these all look like golang defaults, golang rotates secrets after one week by default).
Currently syncthing client’s don’t seem to do any resumption, as the golang config used for announcement doesn’t set a session cache, resulting in no resumption. Enabling that client-side (assuming it also works server-side) with reasonable lifetimes (>= 1 hour) could cut down on TLS resources quite a bit without sacrificing security - the TLSv1.3 PSKs have reasonable security properties, including PFS. Performance-wise it reduces the handshake by two P-384 signatures. It also saves some bandwidth, as server-side certificates do not get re-transferred (they should still be available in code, as the session cache remembers them). [Client-side certificates are implicitly retransferred via the PSK/session ticket].
*Except ECDHE, which is roughly 1/10 of the running cost of ECDSA according to my benchmarks. x25519 is a reasonably secure and fast choice here.