Why FTDI and not AVR with built-in USB controller?
There are quite some reasons, but they are, at least for most people, fairly niche.

The reasons that I see and have experienced


The choice in USB enabled AVRs is quite limited, especially the TINY family. If for some reason an AVR is required that does not have a combination of USB and some other peripheral, this is an easy option. One example that springs to mind is PLL-enabled AVRs.
Even though the USB peripheral is implemented in hardware, you still need to put a USB stack in firmware. This takes up quite a lot of resources (e.g. LUFA requires at least 6kB flash and 1.5kB RAM for a full CDC implementation, and this is one of the most lightweight libraries)
USB interrupts and USB bus events take up resources that can mess with timing-critical firmware. For instance: high-speed ADC measurements can get messed up very badly when a USB task interrupts.
Not all USB library implementations work as well with all USB-enabled AVRs. For example: USB bootloaders using LUFA do not work with XMEGA devices. 
FTDI uses signed drivers that automatically install using Windows Update, whereas many USB libraries, for instance ASF and LUFA, do not. This makes deployment to end-users more cumbersome.
Some implementations have lower performance, for instance FT2232H is able to bridge a FIFO to USB at 8MiB/s, which is impossible to do with an AVR.
Many projects do not have full control over hardware and software, e.g. 3D printers have completely separate hardware projects and firmware projects. In order to keep the level of interoperability as high as possible, USB and microcontroller functions are separated.


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.