Both MBR and GPT disks (generally used for BIOS/CSM and UEFI, respectively) require one partition that is not encrypted. The system-verification/key-unwrapping/decryption code has to live somewhere that isn't itself encrypted, after all! The distinction between creating a small (~100MB for Bitlocker; not sure about Veracrypt) primary partition in MBR and putting the bootloader/decryption code there, vs. using the UEFI System partition, is essentially meaningless.
Unfortunately, this applies to evil maid attacks too. There are integrity checks in this code to try to detect when it's been tampered with, but they are inherently insufficient; an attacker can simply replace the unencrypted boot-time code with modified code that lacks such checks (and also steals your encryption key). Again, there's no difference between MBR and GPT disks, here.
The reason Secure Boot is more secure is because it prevents tampering with the bootloader / decryption code, unless the attacker can install a signed replacement where the signature is verifiable with a key that the UEFI trusts. Still, that has nothing to do with the difference between encryption on MBR vs. GPT; it's just that secure boot, as implemented on x86-family systems, requires GPT.
If you aren't using Secure Boot, booting in UEFI mode from a GPT disk with an encrypted OS installation is no more secure than booting in BIOS or CSM mode from an MBR disk with an encrypted OS installation. If you are using Secure Boot, you need to also restrict access to the system setup utility to prevent an attacker from installing their own trusted certificate for modified boot code, else a moderately sophisticated attacker with unattended physical access could pull off an "evil maid" attack anyhow.