The difference is in software & functionality, which affects the hardware greatly.
The FTDI JTAG cables uses a command set to produce JTAG signals. These are very low level commands, often going into the exact details how the JTAG statemachine works and is operated. The logic of sending the correct commands for your setup is done on the debug host on your PC.
This is functional, cheap hardware, free software (GNU GCC+GDB+OpenOCD), etc. It is flexible enough (because of the low-level command set) that there are ports for ARM debugging, FPGA programming, or generic JTAG chain scanning.
The commercial cables are much more specific to a platform and often contain logic within the cable. This allows the PC program to talk to the device in a more abstract way which can be faster.
For example: look at the JLINK USB protocol. It contains commands like EMU_CMD_WRITE_MEM_ARM79. The FTDI cables can also execute this command, but it is translated on the PC side to the low-level JTAG commands the FTDI cable understands. It also means the high-level command (write some memory) is broken down into many more sub-commands, which the JLINK can do on the cable it self. This can result in better latency (taking into account the limitations of USB) and/or higher speed.
It is also up to the IDE commercial vendors which cable they support, and it is more likely that a commercial cable is supported. On the other hand, it is more likely the free IDE's will support the cheap FTDI debug cables.
Some commercial software also contain support for software code breakpoints, where you can set more code breakpoints than the hardware allows for.
Using trace functionality of some microcontrollers requires very fast hardware to capture a 4-bit parallel bus. Hardware capable of this feature often contain a FPGA to do so.