Why isn't X feature part of core?
A common question, particularly by relative newcomers in the Drupal community, is "Why isn't feature X in core?" Feature X is usually either a "utility" module that's used by almost every Drupal website, such as CCK or Views, or a module that's necessary for some types of websites, such as Fivestar or LoginToboggan.
Innovation vs. stability
One of the biggest arguments for not including something in core is that once something's in core, it tends to get "locked down." For example, the taxonomy system has changed hardly at all since it was introduced back in 2002 in Drupal 4.0. Free tagging was added in Drupal 4.7, some form cleanup was done in Drupal 6, but otherwise the underlying structures have remained unchanged for over 6 years.
For a flip-side example, the Views module was completely re-written between Drupal 5 and Drupal 6 and vastly improved in innumerable ways. Its original incarnation could only handle creating lists of nodes. The re-worked version could handle lists of anything: nodes, taxonomy, users, you name it. This is possible because contributed modules, even critically important contributed modules, have a lot more flexibility to change things on the fly than does Drupal core.
It's therefore very important that modules be properly vetted in contrib before they're moved into core, lest core be stuck with sub-optimal features for years. Any feature that we add to Drupal core needs to be good enough to last us at least 3 years in a relatively unchanged state.
Maintenance
People often lament the fact that when you download a package such as Joomla! you've given lots more functionality out of the box. Drupal core is relatively simple; while you can build a small community site with the tools in Drupal core, building most serious kinds of sites requires a trip to Drupal contrib.
However, remember that the more code that's in Drupal core, the longer it takes for the development team to get it properly tested and a release out the door. There's also far more likelihood of subtle bugs being introduced in one part of the code that affect many others. Keeping core small, with plenty of opportunity for contributed modules to "hook" in and extend it, is the Drupal way.
Some people might argue that longer release cycles can only be a good thing, since they dislike having to update their websites every 18-24 months. But remember that an important part of why we all use Drupal is its constant improvements, each release opening up newer possibilities than before. We need to ensure releases are often enough that the resulting effort can be used to ramp Drupal website building to the next level.
Time and resources
It takes a long time to get things into core. Unlike contrib, which is essentially a "wild west" where each module maintainer plays in their own sandbox with relative impunity, every single line of code that goes into core is meticulously scrutinized. It has to be, because Drupal core is used by literally millions of websites, and this attention to detail on the part of the community is one of Drupal's key strengths. Most changes to core go through dozens, if not hundreds of revisions before they're deemed worthy by the larger community.
Even on ubiquitous modules such as CCK and Views that almost every Drupal site uses, there is only a small handful of people (often a single person) doing any sort of major development work. The maintainers for these modules often have their hands more than full just keeping up with bug reports and feature requests for the module for the current versions of Drupal, and often doing so on their own unpaid time. Time spent getting things into core is not spent providing support for the module for all of the hundreds of thousands of people using it right now. Often, efforts to bring these modules (or important aspects of these modules) into core requires additional developers to step up, or funding of the module maintainers.