The key here is privacy vs integrity.
If your data volume (/home, /var/log and anything else with sensitive data) is encrypted then you're primarily just assuring privacy, whereas for /boot you want to make sure no malicious code is placed (integrity). Note this does not imply that it needs to be encrypted. /boot almost never requires actual encryption, since it does not store private/privileged data. I'm going to presume you have locked down booting from external devices (USB).
After the UEFI/BIOS code, the first piece of code executed on your system that you control is the bootloader (e.g. grub), which reads configuration files (that may have security parameters such as disallowing boot option editing), and then your kernel+initrd, also stored on /boot. It will take a determined adversary to:
- Gain physical access to your laptop
- Remove the hard drive without you noticing it's been removed and replaced
- Replace Grub/Grub's config/kernel/initrd with a malicious version (e.g. that captures keypresses, loads hidden daemons, or even starts a hypervisor to encapsulate your entire OS)
- And deliver it back to you with no sign of tampering, performance loss, random bugs or noticing it's been missing.
It is feasible though. If you're at this level of paranoia as opposed to simply keeping your data volume hidden from random search and seizure, then you need to look into a full trusted boot setup. That's a lot of work.
A simple mitigation would be, once your system is started, check that the hashes of all files on /boot are as you expect by comparing it with a previous baseline of hashes stored in your encrypted volume. This is an after-the-fact measure though if /boot has been compromised, but at least you will know about it, and you will need to update the baseline each time you update files on /boot (e.g. new kernel version/new grub security options).
Any more assurance will require a lot more work. Trusted Boot on Linux/*nix is notoriously tricky.