but more than 4 cores is of little benefit to a programming and compiling, unless your job involves writing very parallelizable code.
It appears you seem to be implying there is a link between the degree of parallelizability of the execution and compiling of a piece of code; but there is none that I know of. Afaik, msvs makes great use of additional cores during compilation (although you may have to enable it in the options for C++). Compilation involves a lot of steps which are trivially parallelized.
I wouldn't jump all the way to trivially-parallizable. Yes, many build steps and modules can run in parallel, but also the way that you structure your code has a great deal to do with it, because you, as a programmer, can create serial dependencies between code. Well-written code avoids this (not just for build times, but for general modularity as well), I concede fully that more cores will build this kind of code more quickly, until you reach other system bottlenecks. But what I contest is this -- either your code is *not* well written in this way, in which case you will gain more by re-structuring your code, or your code is written this way, and it probably already builds acceptably fast on a machine with 4 cores -- faster by any margin is always "better" of course, but unless you're re-building very large code-bases completely, with relative frequency, its unlikely that having or scaling to 8+ cores is going to be of any great benefit to you -- unless, perhaps, you're the type runs *nix of some flavor and builds all your software from source. Otherwise, most of us don't build in sufficient volume.
Keep in mind that going from a 4-core intel CPU to an 8-core model running at the same clockspeed will cost you 3x as much at a minimum for the CPU alone. A supporting motherboard will likewise come at a premium. If you go Xeon, you'll also need ECC RAM, another premium, and a still-more expensive motherboard.
For compiling code, hyperthreading does quite well on its own -- between 20-30 percent throughput increase in benchmarks of popular open source projects -- which is why the 50% price premium is well worth while in going from a 4-core i5 to 4-core-4-hyperthreads i7 of equal speed. You can see some analysis here: http://blog.stuffedcow.net/2011/08/hyperthreading-performance/
But the structure of C++ itself is a problem, at least for now. This is part of the reason we have idioms like pImpl/Firewall, and all of the reason why they speed up build times. One needs to look no further than Go, D, or even C# to see that those languages compile in seconds what would take C++ possibly minutes, with no special effort on the part of the programmer -- A speed that even fast C++ compilers like CLang can't match, even with source that does make special effort to increase build throughput. If they manage to get Modules into the standard one of these days, the picture might change, but for now its a trait of the language that can only be mitigated.