By the way, I don't think anyone has brought this up yet.
How do we know that in the future this, or similar actions taken in FTDI's driver won't accidentally brick legitimate FTDI devices? I can easily envision a particular - maybe old - hardware version of one of their devices being left out of a test matrix and then suddenly FTDI (and their customers and customers' customers) are hoist by their own petard.
No, the risk is too great now to use FTDI chips - legitimate or otherwise - anymore.
The way the bricking works, that seems unlikely - there's no per-device detection, it's already 'trying' to brick all devices and authentic ones are just not vulnerable to the method used.
Actually, they do detect what
type of device is plugged in, and only issue the bricking commands to FT232RLs. In fact, the same commands will brick other genuine FTDI devices with an external EEPROM too, if the code didn't check for them. The FT232RL is the odd man out; the clones actually behave the same as FTDI's other chips, which is what their USB command protocol was clearly intended to do. FT232RLs have a buffering hack due to their EEPROM layout, and that specifically is what the clones didn't catch on to, and what the bricking code exploits.

Sidenote: code bug here. They forgot to return a value for non-FT232RL devices, when the if branch isn't taken. This caused the return register to contain an uninitialized value - in this case, the FTDIDevice *dev parameter - which confused the decompiler into thinking the return value's type is FTDIDevice* instead of int (I could've fixed the type but didn't bother). They don't use the return value in the caller, so this is harmless, but still, bad FTDI, ignoring compiler warnings. Doesn't instill much confidence that they don't even check for compiler warnings on their critical bricking code that might brick legitimate devices if it malfunctions.