Most (if not all) of these are just shims to call native APIs, as Jeroen says. So basically:
MsiReinstallProduct is not a "reinstall", it's a repair. You'd only call it if the product was actually broken in some way (or you want to check it). The parameters say what you want to repair. I don't know why it wouldn't repair shortcuts except for the obvious reason that they were not installed by the original MSI in the first place. The WMI call seems strange to me considering that the native API uses a bit mask of everything you want to repair, and but WMI's Reinstall seems to take a single number, so maybe you do need to call it multiple times.
Configure is MsiConfigureProduct, and I've never found a good use for this except for uninstalling where you configure the product to be absent.
Heath Stewart did a lot of work exposing MSI to PowerShell, that may be more useful:
https://github.com/heaths/psmsi
You can set logging policy while you run your tests and look at the msixxx.log files in the temp folder - there may be some clue as to what's going on, such as making sure you've got the right product, what Windows thinks it's repairing etc. It doesn't seem to me that the WMI classes are very helpful here, which is why Heath's interfaces my be much better at this.