Fundamentally, the issue is not the partition table type (GPT vs. MBR); it's the firmware type and boot mode (EFI/UEFI vs. BIOS/CSM/legacy). Windows ties them together quite tightly -- Windows may boot in EFI/UEFI mode only from GPT disks, whereas it may boot in BIOS/CSM/legacy mode only from MBR disks. Because of this, if you boot the Windows installer in EFI/UEFI mode and it sees an MBR disk (or in BIOS/CSM/legacy mode and it sees a GPT disk), the installer will complain or convert the partition table type.
The boot mode for the Windows installer can be controlled by the user, but the methods for doing this are non-obvious and vary from one computer to another. At best, when you enter the computer's boot manager (typically by hitting a system-specific function key soon after you power on the computer), you'll see two options for the boot medium, one of which includes "UEFI" in the description and one of which doesn't. The item with "UEFI" in the description boots to EFI/UEFI mode and the other one boots to BIOS/CSM/legacy mode. Note that one mode or the other might be unavailable depending on how the boot medium was prepared; some tools set up boot media to boot in only one mode.
Ubuntu is not so limited; you can install to a GPT disk in BIOS/CSM/legacy mode and the installer won't complain. I don't recall offhand how the installer reacts to an EFI-mode installation to an MBR disk. It might or might not work, but you can definitely coerce an MBR installation to boot in EFI mode if you know what you're doing and if your firmware doesn't freak out about it.
The critical detail is to get both your OSes' boot modes to be the same, since switching boot modes is usually awkward.
Incidentally, I disagree with your assertion that it's easier to dual-boot Ubuntu and Windows with MBR (and, by implication, under BIOS/CSM/legacy mode). This was true with old computers that simply did not use EFI; but with modern EFI-based computers that support both boot modes, enabling both modes (which is normally required for BIOS/CSM/legacy support) creates additional boot paths and therefore additional ways to screw things up. It's this, not EFI mode per se, that causes most EFI-related headaches. Unfortunately, there's a lot of bad advice out there to enable BIOS/CSM/legacy support, install Ubuntu in that mode, and then clean up the mess with Boot Repair. Getting the Ubuntu installer to boot in EFI mode perplexes a lot of people because of the aforementioned non-obvious and non-standardized controls of initial boot mode; but overcoming this hurdle is likely to be much easier than fixing the problems created by trying to bypass the problem by doing a BIOS-mode install.
There is one caveat to my advice on this score, though: Some EFIs are still buggy and don't remember the OS they're supposed to boot. Thus, you can end up booting straight to Windows after Ubuntu is installed. There are various fixes and workarounds for such problems, and finding the one that's minimally invasive requires a certain level of expertise. I've answered questions about this many times on this forum. One that bubbles to the top is this one.
