Because Linux and windows bootloaders routinely screw with each other. I am NEVER losing another weekend to that crap again. Dedicated windows gaming PC is the correct way to deal with this.
With a UEFI-GPT setup two ESPs (one for each OS) and you're good. Now that I have no software bootloaders, which need to know about multiple OSs, I only need to use BIOS' own boot device selector on startup.
That's not the case for a long time. I have rEFInd that started life in windows 7 esp with freebsd dual booting, now the same hard-drive booting windows 10 (upgraded from 7, not fresh installation) and nixos, all with the same rEFInd from the same.
The correct way to do so, is to have separate hard-drives for different OS. Then there is zero chance of them stepping on each other.
It's a very real and terrifying threat. A standard PC has numerous components with their own firmware that can potentially be flashed. Some of those components may have integrity checking schemes that are supposed to ensure only vendor-signed code can be flashed or executed, but don't rely on those measures actually working as intended (and not being exploitable themselves). Hardware vendors are notoriously bad at this.
This is one of the reasons I'm so enthusiastic about the T2 and M1: a hardware root of trust designed by a competent vendor. (Yes, there is a flaw in the T2, but it requires physical access to exploit.) In my opinion, those are the only trustworthy desktops or laptops on the market right now. You'll notice AWS (Nitro) and Google (Titan) also have their own proprietary hardware security chips for the same reason.
Depends on what the avenue of exploit you're worried about is. You can disable BIOS flashing from the OS in the BIOS, but that might still be theoretically vulnerable to, say, compromising the Intel ME environment and flashing from there; a rootkit loaded in SMM could hang around until the machine is cold power cycled (and theoretically compromise the bootloader(s) to load itself and then chainload the "real" bootloader every boot); if you want to get really invasive, you could theoretically start flashing various microcontrollers attached to the system (say, a USB flash drive, or your HDD/SSD controller) to do malicious things.
These get increasingly unlikely (and unreliable, without knowing and targeting the specific hardware you're using) as your attacker model includes less resources, but not impossible. Intel ME code execution, BIOS and SMM rootkits, malicious USB flash drive firmware and HDD firmware have all been demonstrated (I haven't seen malicious SSD firmware, but there's nothing theoretically stopping it other than the controller doing a lot more on them), and a couple have even been found in the wild.