AES, by itself, is a block cipher: it accepts as input a "block" of 16 bytes, and produces a block of 16 bytes. But we want to use it to encrypt "data", usually long sequences of bytes, much longer than 16 bytes, so something else is needed; this is the mode of operation. The mode of operation defines how the input data is processed, and, in particular, what exactly goes into the block cipher proper.
The simplest method is to split the data into 16-byte blocks and process them independently of each other. This is called ECB. The usual penguin picture (see @drjimbob's answer) is a clear demonstration that there is something wrong with ECB, when processing "normal data". A better encryption mode is needed. Historically, OFB, CFB and CBC first gained popularity, then later on CTR was defined. All these modes make different things with the data and invoke the block cipher on different blocks. In CBC and CFB, AES is invoked of blocks which are a XOR of a data block with some produce of past processing; with OFB and CTR, AES is invoked on something which depends on the IV, key and block position, but not on the data itself.
With a lot of hand-waving, we can claim that in a good mode of operation, the raw data should not enter the block cipher "as is". The reason is the following: normal data has redundancy, so you can expect the source blocks to have repetitions (e.g. think of XML). However, the block cipher itself is deterministic, so if you call it twice on the same output, you will get twice the same output. This is the kind of information leak that a good encryption system should hide. In a mode of operation, the "hiding power" lies in the block cipher; the rest is mere data routing; therefore, in order to hide repetitions and other structural elements of the source data, the mode should be such that no two invocations of the block cipher shall send the same block to the block cipher. And this implies at the very least some pre-cipher processing.
Now CFB and CBC still "combine" the data block with the block cipher input, while OFB and CTR do this combination on the output only. We might argue that the latter method is superior because it allows precomputations: with OFB and CTR, one can "prepare" the pseudo-random string before having access to the actual data. However, this is rarely done, because buffering has its own costs. A much more important characteristic of CTR, that CFB, OFB and CBC do not have, is parallelization: given, say, a 160-byte message to encrypt, the 10 underlying AES invocations can be done simultaneously, provided that you have enough circuitry for that. You cannot do that with CBC, because you have to wait for the result of the encryption of one block to begin processing the next block (you can have parallel CBC decryption, though). High-bandwidth circuit makers love CTR mode (it maps well onto unrolled, pipe-lined AES implementations).
To sum up:
- There is a need for a mode of operation more complex than ECB.
- The mode should include some data pre-processing so that the raw data does not enter "as is" the block cipher. If the mode "directly encrypts the plaintext" (i.e. applies the block cipher on unmodified source data blocks) then it will have trouble hiding repetitions, and that's a problem with normal structured data.
- There is no formal need that the source data enters the block cipher at all; the source data may enter the mix as a post-processing step. This gives some minor advantages, e.g. the possibility to precompute the bulk of the operations; if the post-processing is a simple XOR, it also makes decryption identical to encryption, which is nice when a system must do both (it saves code space and/or silicon area).
- An important feature of good modes is the possibility to speed up things with parallelization. It so happens that the one popular mode which is amenable to parallelization for both encryption and decryption (that's CTR) also is a "post-processing only" mode. That's a coincidence; to my knowledge, there is no strong reason why it should be so. But it is nice nonetheless (as said above) so we will not complain.