The short answer is: No, the presence or absence of unallocated space has nothing to do with the subsequent boot problems you encountered.
To install Linux, the disk must contain either unallocated space in which the Linux installer can create partitions or partitions that already exist and that the installer can take over for use by Linux. If the disk contains neither of these, the installer will shrink an existing partition to make room for Linux. The details of which of these options is best supported and how they're done depend on the distribution and the options you choose during installation. Although the choices you (or the installation program) make during installation can affect the boot process, a complete failure to boot after installation indicates a bug.
On a working EFI-based computer, the computer's NVRAM holds a list of boot loaders and the order in which they're to be used. Thus, you can set GRUB to boot before Microsoft's boot loader, as an example. In your case, many EFI-based HP computers are known to have a bug that makes them ignore EFI boot variables. Instead, the computer blindly boots the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi). This is almost certainly the problem that you encountered.
Ubuntu's Boot Repair tool juggles the boot loaders, moving Microsoft's boot loader to another name and placing a copy of GRUB where the Microsoft boot loader used to reside. It makes several other similar changes. The end result is, as you've observed, an explosion in the number of boot entries on the GRUB menu. If you were using a non-buggy EFI, I'd recommend undoing the Boot Repair changes by re-running it and using the "Restore EFI Backups" options on its advanced menu, as described here. If you do this, though, you'll wind up back with a computer that boots straight to Windows. You might still want to do this and then do a less ham-fisted repair yourself, in any of three ways:
- You can boot to Windows and use Windows' own
bcdedit command to set GRUB as the default boot loader. Open an Administrator Command Prompt window and type bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi. (This assumes that you've disabled Secure Boot. If it's enabled, substitute shimx64.efi for grubx64.efi in this command.) This option might not work, but if it does, it will result in GRUB starting up by default and showing fewer boot options.
- You can boot a Linux emergency disc, mount the ESP somewhere convenient, copy
EFI/Microsoft/Boot/bootmgfw.efi to some other name (I recommend moving it down one level), and copying EFI/ubuntu/grubx64.efi to EFI/Microsoft/Boot/bootmgfw.efi. (If you're booting with Secure Boot active, copy shimx64.efi over bootmgfw.efi and also place a copy of grubx64.efi, under that name, in the EFI/Microsoft/Boot directory.) You'll also need to run update-grub to have GRUB regenerate its boot list and create an option to boot Windows.
- After undoing the Boot Repair operation from your regular Ubuntu setup but before rebooting, install the Debian package of rEFInd. Once it's installed, type
sudo mvrefind.sh /boot/efi/EFI/refind /boot/efi/EFI/Microsoft/Boot. This places rEFInd as the default boot loader in place of Microsoft's boot loader, using a hack that's similar to what Boot Repair does; but it should result in fewer redundant boot entries. There are likely to be at least two ways to boot Linux, though: One via GRUB and one more directly. If both work, you can uninstall GRUB (and perhaps manually delete its /boot/efi/EFI/ubuntu/grubx64.efi file) to remove the GRUB entry. Note that this option requires additional steps if you're booting with Secure Boot active.
Note that you need to do only one of these things, although if you try one and it doesn't work, you can try another one. I recommend backing up the entire ESP before you begin so that if you make a mistake, you can restore the original state of the ESP. A simple file-level copy or creating a tarball should suffice for the backup.
