Why isn't CTR mode (counter mode) used more often? For the CTR mode, the design is good for parallelization, yes, it seems the benchmark of the program downloaded from crypto++ proves that on an Intel I7 CPU. 

My question is that as most of CPU on the computers today are multicore and designed good for multithread calculation, why not all people use the CTR mode as it is much faster than the CFB mode (about 4 times faster on Intel I7-4770K, 3.5GHz CPU)?
There are probably quite a few good reasons for this, although I don't expect that a scientific answer can be composed (as you would need to use a survey, and I've never heard of such a thing for modes of operation).

Let me list a few possible reasons:


Developers don't know about CTR mode of operation; most questions on StackOverflow are about ECB and CBC (I really hope that SO doesn't reflect corporate practices everywhere);
Even today it is possible that CTR mode is not available for some runtimes (only ECB and CBC mode are practically guaranteed on most lower level libraries);
(Older) protocols may simply specify other modes of operation.


With regards to the parallelism provided:


AES is already pretty fast, doubly so if AES instructions are present within the chip - for instance AES-NI within Intel/AMD CPU's - so the parallelism provided by CTR mode are not often required;
Many problems that require fast crypto are embarrassingly parallelizable by themselves (e.g. multiple file encryption and TLS sessions to a server);
Multi-threading is hard to get right, and may be hard to use (for instance, you may not want all your cores to be just encrypting data);


You think in CPU terms. Loads of people however don't use C/C++ but use higher level languages. These may have a totally different level of operation and may not have good support for modes of operation, let alone multi-threading support for these modes of operation.

If you want to create a protocol that is supported on lots of devices you may need to standardize on CBC as highest common denominator. C/C++ may be fast, but software created in those languages is also notoriously hard to secure, leaving you exposed to all kinds of attack. Speed is nice, but it is useless if you lose your data because of a buffer overflow.



In the cryptographic community CTR is probably the hottest mode in town. It is for instance used in GCM, CCM and EAX (authenticated modes of operation) as underlying mode to provide confidentiality. It has one particular cryptographic property that is not nice: nonce (IV) reuse is catastrophic to the confidentiality of messages send with CTR. The IV in CBC mode is harder to get right, but it doesn't fail as badly if you don't.

In the end, CTR mode is often simply not required. But with the advance of AEAD modes that use it for encryption / message confidentiality, it may be that it makes a stealthy comeback; many developers will be using it without even knowing that it is there.