I see you've found a solution, and it's one of several I was going to suggest. (Disclaimer: I maintain rEFInd, so I'm not unbiased.) I do want to provide an analysis to suggest what may have gone wrong, though. Also, I have an important suggestion that may help you avoid future problems.
Based on your Boot Repair output, your first disk (/dev/sda, a 112 GiB disk) uses GPT, has an EFI System Partition (ESP), and has both Windows and Ubuntu (GRUB) EFI-mode boot loaders on its ESP. It looks like Windows is installed on this disk. You also have a second disk, /dev/sdf, a 932 GiB disk that uses MBR partitioning and has both Windows and Ubuntu partitions. It looks like Ubuntu is installed on this disk.
Ordinarily, the partition table type (GPT vs. MBR) is tied to the way the computer boots -- EFI/UEFI mode with GPT and BIOS/CSM/legacy mode with MBR. There are exceptions to this rule, but it's a useful starting point, especially for Windows. Because your computer has both GPT and MBR disks, this creates some ambiguity; but it looks like Windows originally booted in EFI mode from the GPT disk. Since everything used to work, I'd further hypothesize that Ubuntu was installed in EFI mode, too; but the Ubuntu installation booted from the ESP on /dev/sda to the actual installation on the MBR /dev/sdf. This is perfectly legal; however, it probably led to problems because of an assumption in a script somewhere. This is where I begin to move beyond fairly safe inferences into the realm of sheer speculation. In particular, my guess is that you did a software update in Ubuntu that ended up either breaking GRUB's ability to boot Windows. This can happen sometimes, especially if the Windows Fast Startup and/or Hibernate features are active. These features can cause filesystem damage, which can make the Windows boot loader seem to disappear or malfunction, either temporarily or permanently. Thus, it's imperative that these features be disabled, and I suggest you do so. See here and here for instructions on doing so.
You then exacerbated the problem by performing recovery actions that were designed for BIOS-mode Windows installations. This put a BIOS-mode Windows boot loader on the first sector of /dev/sda, among other things. Given that rEFInd worked, at least these attempts didn't damage anything further, just added useless cruft.
In any event, installing rEFInd bypassed the hash that is now the GRUB configuration, thus getting things working. If you're happy with rEFInd, you might as well keep using it. An alternative would be to try to fix the EFI-mode GRUB installation. Boot Repair can often do this, although your computer's odd mix of MBR and GPT, as well as traces of both EFI-mode and BIOS-mode GRUB installations, might confuse that tool. Thus, unless you're seriously unhappy with rEFInd, it's probably best to follow the adage "if it ain't broke, don't fix it." I do strongly advise you to disable Fast Startup and Hibernate in Windows, though; even if rEFInd can launch both Ubuntu and Windows now, if those features are active they could cause new problems in the future.
