I was about to write something similar. You're just pushing the problem down the stack, and argon2 doesn't fix that particular one anyways.

The facts are:

1. You always need an unencrypted entry point, so encryption can't be your secure anchor (though it could never be anyways, you're looking for authenticity there, not confidentiality)
2. As the original post states, making sure an attacker never has physical access to your boot or EFI partition works against that particular evil maid attack. It won't protect from other threats however and isn't very practical.
3. You need to authenticate your whole boot chain for actual protection, including initrd, which the linked article also rightfully points out
4. The only system available to normal users to provide authenticity protection mechanisms is Secure Boot (with implementations not always perfect)
5. In practice, you need to enroll your own keys to sign your initrd and have a mechanism to actually check it, or use something like a signed UKI
6. In your actual system, make sure your boot partition is only available to root - EFI mandates vFAT which doesn't support owner attributes, so put on a restrictive mask (0077)
7. Your UEFI needs to be protected by password so that an attacker can't just disable Secure Boot and replace your protected files

With all these in place, you should set up booting from an encrypted partition where they key is loaded from the TPM with sufficient PCRs bound and a PIN or something similar. I'm unaware of current solutions to easily have a kernel check against the registers during boot, so in case your system won't decrypt with the PIN as your input alone, you know that your boot process has been altered (not necessarily malicious, could be a firmware update, but still).

Real security is hard, there is no easy solution if the vendor doesn't control the hardware (which both Apple and Microsoft do), most users don't care that much that distribution would push for it. You rather still have the unhealthy "open source is secure and TPM / secure boot is a Microsoft tool to lock out other operating systems" attitude.

PS. this is not meant as a guide for setting up a secure system, just some considerations when considering the approach.

Can't Ventoy bypass secure boot with the shim thing? i.e. ENROLL_THIS_KEY_IN_MOKMANAGER.cer

Or is secure boot just to ensure that "this kernel uki hasn't been tampered with"?

Furthermore, if it's secure boot autounlocked by TPM, won't I have to password protect my bootloader too to avoid kernel parameter oopsies? (Lol changing kernel parameters right then and there reminds me of the windows utilman trick)

The secure boot route seems fraught but perhaps I'm looking at it wrong

TPM can be the fix, but it needs to be integrated into the boot process correctly.

https://0pointer.net/blog/brave-new-trusted-boot-world.html mentions some or most of the pitfalls