In case anyone was still wondering if this is intentional and malicious...
Straight out of their driver. Function/variable naming and comments mine.
Edit: Ooooh this is cleverer than I thought. So what's going on is that on real FT232RLs, the EEPROM is written in 32-bit units: writes to even addresses are buffered, and writes to odd addresses write 32 bits at once: the buffered 16 bits, and the supplied 16 bits. So, on a real FT232RL, this code does nothing; it just buffers 16 bits then buffers another 16 bits and no writes are issued. On a clone FT232RL, this writes the PID to 0 (breaking the checksum) and writes not the checksum, but the value required to make the existing checksum match
to address 62. In combination, these two writes make the checksum at address 63 valid again (without modifying it). I've updated the image above with the new analysis.
Edit 2: Note that the EEPROM write commands are legitimate (and necessary - but not sufficient - when writing the full EEPROM of an original FT232RL), and indeed I think they would work on (i.e. also brick) other FTDI devices with external EEPROMs (the code that calls this function is very careful to only do so after detecting an FT232RL, legit or not). What seems to have happened here is that, when FTDI switched to an internal EEPROM on the FT232RL, they decided to switch to a 32-bit EEPROM (you can actually see the 32×40 bit array in this die shot
by Zeptobars). However, they kept the existing 16-bit-at-a-time commands, but instead decided to buffer one and write only when the chip has accumulated a full 32 bits. This keeps the PC side the same across their entire chip range. The clones just emulate the established interface in the logical and obvious way, issuing 16-bit writes, since presumably nobody checked that a real device doesn't respond like that since usually the entire EEPROM is written at once. FTDI realized that this difference of implementation existed, and is exploiting it here by carefully crafting a routine that has no effect on the original device, but bricks clones (and would likely brick legitimate non-232RL FTDI chips too!).
In a way, the clones actually implement FTDI's command interface better than FTDI themselves - and FTDI is exploiting this to brick them.