This is a fundamental decision I have been faced with on a nearly daily basis for the past 6 month: "Do I start this project on a base of Drupal 6 or Drupal 7"? Why is this an issue? Typically, when faced with a decision with a version, the automatic (and proper) response is to answer that with, "The latest and greatest.". However, as I write this, the decision with D6 vs D7 is not that cut and dried.
Recently I had to make this decision for the very site you read this article on. Do I go with a version of Drupal I'm most familiar with (D6) or do I upgrade to D7? For the longest time I avoided D7 simply for the fact that, traditionally, one avoids applications that are version x.0. I gave D7 a fairly wide berth until about 3 months ago when I was finally in a position to get my hands dirty with it. As of December 2012 D7 was at version 7.10, a nice round number, relatively safe for implementation on production servers. However, Drupal 7's state was only one part of the equation, and in actuality a minority issue. The real question arises when you look further down the path of planning the implementation at availability of third party modules.
For a practiced Drupal developer, earning the numerous API [1], [2], [3] changes to Drupal 7 compared to Drupal 6 is merely an exercise in reading documentation and committing those changes to memory. It probably goes without saying that third party modules are a huge time saver for you and money saver for your client and checking for their availability for certain aspects of your requirements is an early step in your planning process so you know how much work you will need to devote to solving a particular spec if it hasn't been already addressed in module form.
Drupal 6 is a very mature platform, having been in release since February of 2008 (wow, has it been that long?). 4 years is practically a lifetime in Internet time! The net benefit of that vintage is the fact that there are 4 years of modules out there. If there's a problem or feature you're lacking in your Drupal implementation, there's a pretty good chance that someone else has, too, and taken the steps to make that solution available as a module. Drupal 7 has been in release for 7 years, which, too, is a significant amount of time. However, when searching for third party modules for your Drupal 7 it's not uncommon to come up short! Modules that you may have taken for granted in D6 may not yet be available in D7. In some cases, their page may say it is no longer being maintained after 6.x. Many modules might exist, but they're in 7.x-dev state or some form of 7.x-RCn (release candidate) form. Do you trust your client's precious web site to the hands of a dev or RC module? What happens when that D6 module you have in your standard D6 kit doesn't exist in D7 and your client is asking for that feature? Are you able to write it yourself or cobble it together from a few other D7 modules that offer part of the solution? How do you present that cost to your client?
This is a scenario that I have actually faced a number of times, even in the process of updating our very own website. For example, a module that I have come to rely on several times is the Node Gallery module. This is a very nice module that allows you to quickly set up an image gallery that includes a very nice multi-image upload tool, ordering and management tools as well as jQuery popup integration. In fact, it has it's own set of sub-modules! But, unfortunately, this functionality is not available at all for D7, not even in alpha/beta/RC form. The alternative was to attempt to create approximate functionality with Views, which worked, but was less than ideal, and lacked a large amount of functionality and extensibility of Node Gallery.
Another example has been determining if D7 is a suitable platform for Ubercart implementation. A number of modules that I commonly rely on for a shopping cart implementation are not yet available for D7 in a full 1.x release, if at all. The additional challenge here is that when having to develop your own module to fill that gap is that you are not just writing against changes in D6 to D7, but learning the intricacies of integrating with Ubercart as well, a very large and complex application by its own right.
Doom and Gloom?
No, it is not all doom and gloom. D7 is a very powerful and worthy upgrade from D6. Many modules that were formerly third party modules are now fully integration functionality of the core, such as CCK and "Image cache", both indispensible D6 modules. Many D6 modules do have a D7 version out and you can get a very functional D7 site up and running just as easily as you could D6. With D7 you have years of future support where D6 support will eventually come in the form of security fixes, though it, too, will stop being supported in any fashion.
Considerations
A critical point of deciding over D6 vs D7 is the idea of "future proofing" the client's site. "Future proof" is an absolutely loaded term and really means nothing, but the idea is that you can buy time between major upgrades by using the current version of an application. At some future point, D8 will supersede D7 and developers will be faced with the same dilemma that I am describing here, however, A D7 to D8 migration should be less painful than a D6 to D8 migration. Many of the API changes in D7 may be a part of D8, though it's inevitable that new API changes will appear in D8 as well.
If the site you are building is to remain fairly consistent, perhaps with an update a year or two down the road, they may be satisfied with a D6 installation. You are counting on, to some degree, that the D6 functionality and modules you are using today, will eventually be ported to D7 or D8 when the update is to occur. Hopefully, the cost of a future D6 to D7 (or even D8) upgrade as part of their site upgrade is something they are going to be ready for. Is there a key piece of functionality that an existing D6 module offers that does not exist in D7 that could be a show-stopper for your implementation? (i.e. are you forced to use D6?) Is the client willing to afford the price of your or your team developing equivalent functionality as a D7 module?
This is a fairly crucial juncture for making a D6 or D7 decision. D6 is fully matured with the breadth and wisdom of a long career. D7 has climbed the ladders of achievement and is ready to take on the world. You have to weigh the longevity of your client's site and if they will be better served by D6 or D7, or willing to pay for the development costs of filling in the gaps where a missing D6 module's functionality would have existed.