It's also going to need to connect to both SCK and SDA and 3.3V and GND to do anything on the bus.
  Typical I2C topology only has discrete 10K pullups to VDD, can't do much with a 2 pin device that's in an 0201 package.

It's actually quite likely, if this chip/mod/hack whatever causes a problem, the board will be pulled and sent for repair.
Of if the board comes in for something else and the odd part is noticed, when you look at these boards all day, something different sticks out.
Someone's going to inspect that board and do some analysis to see if it's a problem that affects thousands of other servers.
Once one chip gets found, the datecode printed on the board will identify the factory and production date.
That would start a purge of all the boards and a major blacklisting of the manufacturer.
None of the big guys (Foxconn, Wistron, Inventec, Quanta etc ) would risk it, the tracking would point right back to them.

Supermicro has the BOM, Schematics, Layout files, they , pre the article are not in on the hack and would be motivated to clear their name.
If there is a chip inserted in between layers, you won't need a BOM to find that, no one does that on mass-produced serverboards, it's far too expensive.

Now, if there is a part that is nominally on the board, is part of the schematic and BOM , but has been replaced with a modified part, you wont find that on the paper work or even layout, you'll have to find a board with the part on it. I could see a reel of parts with the same footprint being substituted during a production run, but that means hundreds or thousands of boards are in the field.

Surely some Engineer or Tech has one of these in a box that had failed for an unrelated reason, or were part of an engineering test or even a spare. There are only so many parts that are potential candidates for substituion, ie ganged pullups on the I2C lines , a single 2 pin package wont be able to affect or read data, buffers or possibly a filter on the RMII lines from the BMC MAC to the management network PHY , filters or baluns on the PHY to RJ45 network jack, the jack itself. the BMC boot EEPROM all come to mind.

That's the problem with a hardware hack, it's going to leave a physical evidence trail. So far nothing has been produced.
IMO this story is unraveling.

The one thing I've yet to see is one of these devices.
If they got into the supply chain and made a production run of boards with these parts, there should be hundreds if not thousands of modified boards in multiple datacenters. Surely some engineer or tech has a failed or spare board in a box somewhere that has this part on it. If there was such a purge of servers once this became known, people would have talked by now, or someone would know and again have an old one or a lab board that they could pull this part off of. Getting into the supply chain at the board house is a single point, but the back end of where those boards went, that's hundreds of people.

As to where you'd put the device, another place would be between the management PHY and the BMC , the AST2400 otherwise connects to the Southbridge
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.aspeedtech.com%2Fpro...
You'd not going to have direct access to the CPU there.

IMO a 'Plausible' hack, but until someone can produce one of these 'spy filter' chips, I'm not buying it.

I'd love to have Open Source firmware for my DJI P3, the hardware is really nice, but the restrictions and auto upload and forced updates by DJI are starting to annoy me.
Sure, they're the biggest target and they'll do whatever the FAA asks to keep their market share.
"Nice business there DJI, it'd be a shame if anything happened to it"

You could always read the original paper
: A Single Dose Respiratory Recombinant Adenovirus-Based Vaccine Provides Long-Term Protection for Non-Human Primates from Lethal Ebola Infection
  http://pubs.acs.org/doi/abs/10...
is a link to the abstract, the full PDF requires a free registration

Far more likely, there's a bug in an interrupt handler that corrupts memory used by the throttle position servo.
If they forgot to put a lock around a read-modify-write operation, it could get hit under unexpected operating conditions, that could be triggered by cosmic rays, ie a memory access exception handler routine.

The brake failure could be caused by the anti-lock system, but that's always a separate processor.
Having that fail in a no-brakes mode, and the throttle fail in a wide open mode, seems really improbable since both sorts of failures are worst case and would imply some sort of interaction between the engine controls and the braking system. Those should be totally independent systems.