I read the original article, but I don't see any part where someone recorded what was going out the speaker and looked at it. If someone is sending data over audio, it will show on a scope. Clearly that's not going to do much unless the receiving side has some kind of modem code listening for it.
Then there are claims like "It seemed to send TLS encrypted commands in the HostOptions field of DHCP packets." Attacking via DHCP packets is plausible; DHCP clients get told a lot of things they're supposed to do, and some of the older vendor-specific extensions are very insecure. But TLS? TLS isn't used within the DHCP protocol itself. There's a way to store DHCP configuration info in an LDAP server and have a DHCP server access it via LDAP.
If someone is seeing strange DHCP packets, and reloading the BIOS won't help, it's possible that what's going on involves an attack via the network controller. The fancier network controller parts now have CPUs and EEPROM. This may be an attack which puts code in the network controller which in turn patches the BIOS.
The people studying this need to list exactly what network ICs the machines involved are using. Some network devices are too dumb to be used as an attack vector, but some have whole protocol stacks, WiFi support, remote administration support, etc. It would not be surprising if those were attackable.
I've expected attacks via network controllers for years. That's been used to attack servers. There's a known attack on PCI controllers which can survive rebooting and reloading the BIOS.
If the machine has wireless networking hardware and the attack exploits the network controller, it may be able to do wireless networking even if the user thinks they have the hardware disabled. Time to open up the machine, clip onto the JTAG port on the network controller, and read out the device memory with a JTAG debugger. Compare the dumps with other machines.