This sounds just like the problem I had with my previous home desktop system.
HP Probook 450 G0 uses a Mobile Intel HM76 Express chipset, which is also known by Intel development codename "Panther Point". My desktop that had this problem also had a Panther Point chipset.
The actual problem is that the XHCI USB controllers of the Panther Point and Lynxpoint chipsets need to be shut down in a particular, controlled way, or else they will promptly wake up the system again. Infuriatingly, different versions of the chipsets will need different shutdown steps, and the fix for one version actually triggers the problem for another. Some (perhaps most?), but not all, BIOSes handle it automatically, so the problem only exists on some subset of systems using these chipsets.
You'll find a long discussion about this problem in: https://bugzilla.kernel.org/show_bug.cgi?id=66171
In a nutshell, there are two quirks defined in the Linux XHCI driver code for this issue: XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT. Depending on the exact chipset version, you might need one or both of these quirks enabled.
You can enable the XHCI_SPURIOUS_REBOOT quirk by /etc/modprobe.d/*.conf line options xhci-hcd quirks=8192, or with kernel boot option xhci_hcd.quirks=8192.
To activate the XHCI_SPURIOUS_WAKEUP option, use the value 262144 in place of 8192; to activate both quirks at once, use the value 270336 (= the sum of the two values).
Try the kernel boot option route first: it will work regardless of whether the XHCI driver is built into the main kernel or loaded as a kernel module. If you find an option that fixes it for you, adding it to a /etc/modprobe.d/*.conf file might be a "cleaner" way to make it persistent if the XHCI driver is loaded as a module.
Since USB drivers are essential for USB keyboards, the XHCI driver may get loaded early in initramfs phase of the boot process, so after making a change to /etc/modprobe.d/*.conf, remember to rebuild your initramfs file (dracut is the current initramfs tool in Fedora, I think?).
Leaving the XHCI driver unloaded will also exhibit the problem, as with no XHCI driver present, the kernel won't know that the XHCI controller needs special attention at shutdown.
