Many programs now a days are optimized for 4 threads.
Incorrect. Most programs aren't even optimized for 2 cores, let alone 4 or 6. Some are yes - but that's mainly restricted to very specialist applications; usually the ones that come with 4 figure price tags.
The issue is that coding in a multithreaded way isn't easy. You introduce all sorts of potential issues (deadlock, livelock, race hazards) and debugging your code is far harder because you've no longer just got a single path of execution. Things are gradually getting a bit easier, but we're nowhere near yet, and realistically speaking very few people will spend the time optimising for multi-core CPUs when an application runs perfectly acceptably on a single core.
Even some of the best programmers in the world got it wrong to start with with Java's early threading model - a good portion of the original thread methods are now deprecated because they're deadlock prone. This took a long time to come into sight however, and the theory behind it is not trivial. See here
if you're interested but don't pretend to understand unless you're at ease with detailed programming / threading concepts!
Threading is a widely misunderstood subject, and to get right requires a great deal of effort - it's very easy to get wrong and introduce all sorts of horrible potential bugs. We haven't really got a widely accepted method for dealing with these issues and our current programming models (such as OO) don't brilliantly lend themselves to concurrent coding in general.
The main application for multi-core CPUs when you really see their benefit is in server side applications - these have been multi-threaded for years, since each request to the server is generally handled along a separate thread. Beyond that some limited applications can make use of multiple cores, but these are few and far between (and the ones that do it efficiently and properly are even rarer.)