Firstly, since the issue is about INSTALLATION of the Adobe Flash ActiveX product, the truth is that neither WSUS, nor Configuration Manager, nor Patch Manager, are products involved in this problem. I believe that Microsoft Technical Support has told you as much already. Your ticket with SolarWinds support is being discussed internally, and I've provided the same feedback just a short time ago.
Fundamentally this is an issue between the Adobe Flash v11.8 ActiveX installer and the Windows 7 SP1 x64 systems affected, and your most appropriate avenue for investigation and resolution of this issue is with Adobe. As I understand the scenario, the installer has been properly delivered to the client, but the installation fails. As such, neither WSUS, Configuration Manager, nor Patch Manager are subjects of this issue, as all of those components properly performed their purpose (i.e. deliver the installer to the client and launch the installer). Once the installer launches, the issue is entirely between the Adobe Flash ActiveX v11.8 installer and the operating system. It's entirely possible that there are not-yet-identified issues with the Flash ActiveX v11.8 x64 installer and Win7 x64 systems. (As a contribution, I will make a point to deploy the v11.8 x64 ActiveX package to my own systems and watch for any unusual results.)
As for the post at Technet... that post was from 18 months ago about an Adobe Flash v11.1 32-bit installer in November 2011, so I would suggest that discussion likely has very little to do with your current scenario a year and a half later involving Flash v11.8. Since that time, Adobe no longer publishes 32-bit-only/64-bit-only installers. The installers were made architecturally-agnostic with the release of Flash v11.3. Furthermore, the "fix" documented in that threat was entirely superficial. Changing the "Can request reboot" to "Always requires reboot" does absolutely nothing on the client-side equation of the behavior, because that package attribute is an informational only attribute. I'm not able to determine what did or did not resolve that issue with the v11.1 x86 installer, but I do know that the WUAgent does not engage in any behavior based on the attribute that was changed. Whether the WUAgent tags an update as 'reboot required' or not is entirely driven by the result codes returned by the product installer. My inclination is that the reported 'fix' was entirely coincidental and something else is attributable to the resolution of that issue -- something we will likely never be able to determine.
My best suggestion to you in this scenario is to open a support ticket with Adobe and press them to investigate and identify why the Flash ActiveX v11.8 installer is failing on your Windows 7 x64 systems. My inclination is that it might have something to do with the state of the Internet Explorer x64 product, although that's purely speculation on my part.
Another point to be made is with regard to whether the IE x64 browser is actually being used. Fact is, if IE x64 is not being used, then the Flash ActiveX x64 product probably isn't even needed, and the simple solution may be to not install the Flash ActiveX x64 package at all; however, the x86 package may still be required, and that's the second part of this diagnostic effort -- is it the x86 installation that's failing, or the x64 installation?
To determine that, enabling MSI Logging and launching the Flash ActiveX installer interactively may provide some logging detail not currently available via the standard WUAgent functionality.
And finally, there's always a possibility that the behavior is directly related to the installation file itself. Was this an Adobe Flash v11.8 package/installer obtained via the Adobe catalog (and downloaded directly from Adobe), or was this an Adobe Flash v11.8 package/installer obtained from the SolarWinds catalog and downloaded via an email link pursuant to an Adobe Redistribution Licensing Agreement? You mention "CM/SCUP" in your post, but SCUP is not part of the CM/PatchManager environment, so I'm quite curious as to how/when SCUP became part of this scenario.
I suggest having a look at the Flash player install log. On a 64-bit machine, this will be in "C:\Windows\SysWOW64\Macromed\Flash\FlashInstall.log" for the 32 bit installer and "C:\Windows\System32\Macromed\Flash\FlashInstall.log" for the 64 bit installer. If you are using the MSI installer, you could also add a switch "/l* <log file path>" to create an msi log file at the specified path.