The FTDI chip connects on one side via a USB interface to a PC, and on the other presents a UART interface to the microcontroller; to the latter it looks as if a RS232 cable had been plugged into the device through an RS232-UART level shifter.
This has two advantages. On the PC side, the USB interface becomes a virtual COM port, which makes it easier for programs to communicate with it, since they don't need to go through a special USB driver -- they just have to talk to the COM port, and are thus not even aware a USB port is involved at all and do not need to have code to talk to a special USB driver.
Normally the driver for the FTDI chip doesn't need to be installed -- since thee are so many devices using variations of the FTDI chip, the newer versions of Windows and Linux come with an USB/FTDI driver already built-in.
On the microcontroller side, the same is true -- instead of having to write software to function as a USB device (assuming the microcontroller even has a USB port), the firmware program in the microcontroller only has to deal with interfacing with the UART which is much easier. So at both ends, the PC and the microcontroller, the software thinks there is an RS232 cable between the PC and the board, and is not aware at all there is a USB cable instead.
If an FTDI chip is not used, and the microcontroller has a USB interface, then a USB cable can be connected directly between the microcontroller cable and the PC. One can then write firmware on the microcontroller to present a USB "device" interface to the PC. (This is in contrast to USB "host" interface, which would be used for example if a USB device such as a memory stick or mouse was plugged into the microcontroller.)
If possible, programmers writing this sort of firmware try to make use of the HID (human interface device) interface, which was initially intended to be used by devices like keyboards and mice. However since the USB HID driver is always included in the OS (otherwise your keyboard wouldn't work when booting!), it never needs to be loaded, and it is relatively easy to write software on the PC to interface with it.
The most difficult situation is where a special USB protocol is needed. This makes life much more complicated for both the firmware (microcontroller side) and software (PC side) implementers. When the USB device is plugged in and enumerated, the OS (Windows or Linux etc.) will be unable to find a built-in driver for it. So the software for the device must include a special USB driver, which the user will have to install before using the device.
Well, first off, from the PC side, it is impossible to know when the AVR sends data to the FTDI chip, you only can know when the FTDI sends its data to the PC. I'm going to assume that is what you meant.
I don't remember what all functions are in the .NET wrapper for the D2XX interface, but in the raw ftd2xx.dll there is a function FT_SetEventNotification which will do what you want. I'm sure it's exposed in the .NET wrapper somehow or another.
Anyways you create an EventWaitHandle, pass it to that function, and as long as your device is opened, the FTDI driver will set it as signaled when a character arrives. Your program, or your reading loop, waits on that handle, then when a character arrives, you read whats in the buffer and parse away.
Keep in mind, you are still going to have to loop over and over while reading data, but what the event signaling is mostly good for is taking it easy on CPU usage.
Best Answer
There are quite some reasons, but they are, at least for most people, fairly niche.
The reasons that I see and have experienced
However, with ready-to-use USB libraries, the significant cost of FTDI USB bridges (they usually cost more than even very high-end AVRs) and no performance penalty in most applications, it is very hard to justify FTDI chips nowadays if you have full control over hardware and firmware.