You could increase verbosity, and try working up your way from booting a bare minimum, to see when the system hangs, and if it persistently hangs at the same time, in the same way.

My usual go-to is to add debug apic=debug init=/bin/sh vga=0 nomodeset acpi=off to kernel boot arguments and see if I consistently drop into the bare initramfs shell that way, without switching to any framebuffer graphics mode, while also avoiding potential ACPI breakage that may manifest as early boot freezes. Yes, vga=0 is legacy BIOS only, feel free to skip that one if you're booting UEFI. This is not likely to avoid your problem, anyway.

If that works, remove the arguments, from the right, one after another, to re-enable ACPI, then KMS, then automatic framebuffer console setting. If you're still going, change init=/bin/sh to emergency, then to rescue, then remove to boot normally, always with excessive debug output. At that point, boot should freeze again, as you've only increased verbosity. The messages leading up to the freeze should always give a hint as to what subsystem might be worth looking into further - be it a specific module that freezes, which can subsequently be blacklisted by kernel parameter, for example. Let the system tell you its woes before stabbing at its parts randomly.

This does not assume you having a software fault. This procedure uses the kernel init and following boot process as diagnostics, in a way. Unfortunately, it is pretty easy to miss output that is "out of the ordinary" if you're not used to how a correct boot is supposed to look like, but the info you need is typically there. I typically try this before unplugging all optional hardware, but both approaches go hand in hand, really. I've found in modern, highly integrated systems, there's just not that much available to unplug anymore that would make a difference at boot time, but the idea is still sound.

If this becomes involved, you might want to look into using netconsole to send the kernel messages somewhere else to grab with netcat, and store them in a plain text file to post here for further assistance. You might just get a good hint when reading the debug kernel messages yourself already, though!

EDIT: If those two colorful, pixely dotted lines in the lower half of your literal screen shot happen to flicker into view during boot somewhat consistently right before freezing, my gut feeling says it's likely a graphics-related issue. You might want to short-circuit your tests by trying only debug nomodeset, a more brutal debug nomodeset module_blacklist=amdgpu,radeon, or replacing your GPU with a known good model, as suggested.