Doing things not related to interacting with, or "driving", the hardware is the limit for a good device driver. For software in general, not all forms of spyware are illegal (but stealing money is, at least in my jurisdiction).

Whatever the code for changing the PID is, it (supposedly) would work as well for a malfunctioning but real product, as well as a counterfeit.

Since the "making the hardware unusable" step is just setting the PID to 0, the slope doesn't seem too slippery to me. If the manufacturers of the counterfeit chip had their own PID and Windows drivers, they wouldn't have used FTDI's. FTDI here is merely enforcing that chips which are not theirs don't use their PID.

I agree that their updated driver will probably continue to not work with these counterfeit chips, and while it shouldn't mess up the chips' functionality in Linux, fixing the PID in Linux is fairly straightforward.

In the case where the driver will continue to not work with these chips, "bricking" only refers to not resetting the PID which causes the device not to work in Linux as well.

They don't meaningfully own the PID and there are non-counterfeit chips using that PID for compatibility purposes.