Physical security on x86 is a complex topic, as there are a large number of physical attacks not possible on phones, and whether "good security" is currently achievable depends on your definition.
Non-live Attacks
This is the most secure state on both desktop and mobile hardware. If we're simply talking about someone taking a powered off device and then extracting data, full-disk encryption with a passphrase is enough to prevent this. The main danger with offline attacks is the "Evil Maid" Attack--where someone may compromise the device, allow the unaware user to later boot to their OS and enter their encryption passphrase, and then either extract secrets or execute code with privileged access. The classic example is bootloader modification, which can be solved using TPM attestation of a Unified Kernel Image with Secure Boot enabled and PCR 7 measured, or alternatively PCR 4 (changes each kernel update). However, if your method for TPM attestation is using it for LUKS unlocking, then you are opened to several other classes of offline attacks to your data.
However, other Evil Maid attacks exist, such as writing malicious firmware, attaching malicious USB or PCI devices, inserting hardware keyloggers between the keyboard and the motherboard, etc. Some of these data can also be measured by the TPM such as UEFI firmware, but these measurements are more brittle than PCR 7. Secure Boot on the desktop does verify some firmware signatures, but you are trusting a large number of vendors authorized by Microsoft not to have their keys leaked or sign vulnerable firmware. Another possibility is a rollback attack, where the attacker flashes an old (but previously legitimate) version known to be vulnerable to any of your hardware. Then, the attacker simply has to exploit the vulnerability in whatever they flashed once the user boots, such as an exploit on the network card. Secure Boot does not protect against this and many systems don't have any firmware rollback prevention; Android Verified Boot does. Mac's Startup Security Utility also prevents firmware rollback attacks.
Live Attacks
This is where the situation becomes much more difficult to defend. Your key is loaded in RAM, and your entire OS is loaded. This exposes a huge attack surface.
- If there is a vulnerability in your display manager, then the attacker can immediately gain access past the lock screen.
- Unless you have encrypted memory (most systems don't) then your system can be targeted by a cold boot attack where the attacker removes your RAM from the computer and then extracts encryption keys before the data is lost.
- If you are on a monolithic OS and don't have a USBGuard deny-by-default policy (most people do not), then a malicious USB could exploit a vulnerability in privileged USB drivers to execute arbitrary code or access memory. Similarly, vulnerable network drivers can be exploited. Even if there are no known vulnerabilities at the time of capture, all the attacker has to do is wait until a vulnerability is found in the user's kernel.
- Without IOMMU (most systems support it, but often disabled), then the system is vulnerable to direct memory access attacks via thunderrbolt, firewire, or PCIE connections.
- Similar to TPM keystore vulnerabilities, a live CPU can be vulnerable to fault injection attacks used to bypass privelege checks or extract data.
GrapheneOS has stronger protections in this regard due to USB-C restrictions, auto-reboot functionality, and the security model inherited by Android. I admittedly don't know much about Macs, but I assume protections are stronger on new models since Apple controls the entire stack from the hardware to the OS.