The port and port-count properties can be used to override the (presumably incorrect) data in ACPI.
It does not matter how you inject those properties in ioreg, as long as they are injected before the native kexts look for them. This is why USBInjectAll.kext as well as AppleUSBMergeNub do such injections in IOService:
robe.
As to whether you use USBInjectAll.kext or AppleUSBMergeNub to inject the properties... does not matter. It is the same mechanism and same result. I prefer to use the USBInjectAll.kext approach, as I think it is easier to document the ports in an SSDT vs. an Info.plist and it is also not bound to the SMBIOS in use.
The method described in this thread focuses on "fixing" _UPC and _PLD in ACPI instead of trying to override it with ioreg injections. Because _UPC and _PLD are a bit complex, some may find that more difficult to accomplish. In fact, I think most people following this guide don't really understand what they are doing, as they have likely not read the ACPI spec. To the degree that the subject ACPI files follow a certain pattern (depends on who coded it)... in this case a pattern used by whoever provided the ACPI code for Gigabyte, one can follow a "cookbook" instruction like this. But, of course, such a procedure will not be generic as other computers may have used a different BIOS/UEFI firmware vendor. In that case, you would have to gain an understanding of _UPC and _PLD in order to effectively fix the broken code there.
It is for this reason (the complexity of fixing _PLD and _UPC) and the fact that it is very difficult to fix via Clover hotpatching... that use the "override" mechanism using USBInjectAll.kext.