There are really two parts to point 2.

2.a. is about performance. And while not specifically about C++ this article covers the main idea http://www.kegel.com/c10k.html

2.b. is about avoiding deadlocks and race conditions. Threaded programming in C++ is dangerous. For years I would have said, that I could avoid deadlocks and race conditions by virtue of being a good programmer. However, I've debugged enough of my own code to know this is not always true.

If you only use threads for data driven computation, then you greatly reduce the risks. On the other hand if you have multiple threads running around accessing anything and everything in your program then you need a lot of thread locks which is tedious to implement and not well supported in C++ (vs. say the synchronized keyword in Java), does not perform well and still it is very easy to make mistakes. The point is that there is no reason to let threads run willy nilly because you can do event driven programming in C++ (libev, libevent, libuv) and most programs (or rather most parts of a program) are not computationally intensive.

edit: Here's a great resource on the topic of threading. From the SQlite FAQ "Threads are evil. Avoid them." http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....

This paper by the guy who runs Mailinator is really interesting: https://www.mailinator.com/tymaPaulMultithreaded.pdf

It's about Java, not C++, but it's still relevant.

i think this is strange. i'm not a c++ programmer, but the evented frameworks (node.js or vert.x) are doing it the other way round: use threads only for IO (or computation so heavy it's practically blocking). the complete opposite.