If someone manages to access the running raspberry pi though, FDE doesn't protect against that, while the Syncthing's untrusted device encryption does.
The threat model described by the post above you is actually not about physical access. It's about the PI getting hacked remotely.
If you use Syncthing's encryption then at no point is the decrypted content available to the PI. It gets decrypted locally by other Syncthing peers after they have downloaded it.
Besides, there's still a difference between physical accesses: plain and non-targeted (besides how profitable they're expected) burglaries are way more common than violent targeted attacks meant to extract a secret from an individual.
Maybe a better example might be wanting to use a smartphone as the always on sync endpoint. The phone can easily be stolen but with this feature it won't contain the valuable data.
You send it a WoL packet[0], use key-based SSH to log in to the initramfs environment[1], and type in your password. Or if you have a TPM you can just stick encryption keys there. Do note that if the device lacks secure boot or such, this is vulnerable to an attack where the initramfs is modified to steal your password; how bad this is depends on your threat model.
Depends on the setup, disk encryption has disadvantages such as needing to decrypt each time you reboot (and if that's the root partition, you can't really boot unattended). It can be advantageous to not have to trust the server and have a non-encrypted zfs dataset for this.
I've used dropbear-initramfs on both Debian and Ubuntu to remote-unlock hosts with encrypted root filesystems successfully. It'd be nice if it were better supported though.
I would definitely encrypt the stuff on my NAS if it was sitting in my garage.