To my understanding, none of that would have been relevant here. Users copied the executable (disguised as a folder) from the external media (which was one of their own devices, and would have been in the "set of allowed devices" under such a scheme) which was a perfectly normal input device (not some BadUSB hack). It probably wouldn't be hard to get a malware launcher appear "signed", either. Even if we disallow self-signing, the launcher
only needs to be a wrapper to start Python (which can be supplied alongside). Such wrappers are provided
by Python[1]. I don't know if these are signed normally, but it seems pretty easy to imagine.
All the technical "hacking" happened on the non-air-gapped side, so that that computer would put malware onto the USB with a deceptive presentation (an .exe with an icon to look like a folder and with the same name as an expected folder, while the actual folder was hidden). The rest is social engineering (and Windows not showing the .exe extension).
[1]: `pip3.exe` is an example; it's hard-coded to run the Pip module from `site-packages`, but `pip.py` could be replaced. More to the point, these wrappers are automatically created by Setuptools, to run an arbitrary script specified in the build process, from a "stub" included with Setuptools. (All of this is to work around the lack of support for shebangs, of course.) I don't know if Setuptools can or does sign these wrappers. Probably not.