In general, in order for a thread to interact with any resource external to itself (such as disk I/O, other processes, other threads, etc.), it does so through the use of system calls. There are many system calls, many which could be dangerous in the right context, and many which a thread is not going to use. Syscall sandboxing thus restricts the system calls that a thread is allowed to use. Attempting to use any syscalls outside of the allowlist will result in the OS terminating the process rather than allowing execution to continue.
For Bitcoin Core, this is not going to do much during normal operation. However it can help mitigate the effects of unknown vulnerabilities. For example, suppose there were a buffer overrun vulnerability which allows an attacker to execute arbitrary shellcode. Such shellcode could contain an
execve syscall which spawns a ssh daemon allowing the attacker remote access into the machine. If seccomp-bpf is enabled, and the thread where this attack would occur does not allow the
execve syscall, then an attack of this sort would fail because the process would be terminated as soon as
execve were attempted. This can make it harder for the vulnerability to be exploited as a RCE and limit what an attacker can do.