FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):
The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:
If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.
If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.
Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.
However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.
If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.
If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.
A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...
Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.
However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party interoperable parts by lumping all of them in with 'counterfeit' parts and taking measures that make it easier to suppress them, and easier for 'counterfeit' to mean 'compatible with someone who doesn't want you to be compatible with them' rather than to mean 'based on illicitly copied designs and/or sold under fraudulent label'. These are two very different things.