There are a lot of things to consider when making the decision to go with Drupal 7 or Drupal 6. I will provide some general advice, but many factors will be specific to your project. So my first piece of advice is to do a lot of research on what modules are available. This means not only looking to see if there is a 7.x code branch, but also downloading and testing each module. Very few modules are out of the development state right now. This doesn’t mean they won’t work, but it does mean they probably have quirks/bugs/missing features.
The bottom line is that at this time, Drupal 7 development takes a lot longer than Drupal 6 development. There are benefits of course. To me, Drupal 6 is already starting to seem cumbersome and antiquated at the architectural and UI levels. Many of the Drupal 7 features and modules are way ahead of their Drupal 6 counterparts: Commerce versus Ubercart, Field api versus CCK, Entity API versus, well, nothing … and et cetera. Soon Drupal 7 will be better supported than Drupal 6, but right now, it is not.
Module update lag now overshadows the benefits of using Drupal 7. I would recommend that the novice PHP/Drupal API developer not use Drupal 7 at this point in time, because the likelihood of having to debug/patch complex modules or implement functionality with little or no documentation, is high. Also, module interactions are fluid and brittle. In order to get a D7 site working that uses Views, Entity API and Date, you have to install and maintain a changing cocktail of dev, beta and RC versions. Using the wrong combination will earn you a site full of undefined function errors. Suffice it to say you had better know how to disable modules in the database before attempting to use these modules.
These issues should not daunt skilled developers doing work for clients with large budgets. Drupal 7 development is fun and challenging. A little bit of code goes a long way, especially when working with the entity and field API. Also, at this stage in the game, you may get a chance to write some code for the big modules or for Drupal core, because it is likely that a bug in one of these large codebases will block your way at some point and you will have to either fix it or wait for someone else to do so. One word of warning, if you are a Drupal developer who has hitherto avoided learning about Object Oriented programming (I mean beyond insofar as objects are the same as arrays in PHP), now is the time to put aside your trepidation and learn at least a little bit about class inheritance, interfaces, abstract classes, protected properties and other structural conventions for OO. Many of the big modules (Views, Rules, Entity API and others) make heavy use of OO now.
On the user interface side, there are two modules that are important to learn for Drupal 7: Rules and Features. Spearheaded mainly by Drupal Commerce, there seems to be an initiative for making rules events where there were once hooks, with rules action instances taking the place of hook implementations. Indeed, Commerce appears somewhat inert until you realize that most of its more advanced features are configurable as rules. If you want to write a module that adds functionality to cart events for example, you will find rules event invocations rather than module hook invocations. Fortunately, rules and hooks function similarly; the difference being that while rules are are more complex to configure in code, they, unlike hook implementations, can be customized and created in the UI and exported as Features.
As Rules becomes more central to the average Drupal consumer, the Features module gains significance too. Rules are beginning to describe increasingly complex procedures and business logic previously defined in module hooks, and only through Features can this functionality be packaged and reused abstractly. Features documentation is abundant and mostly good due to the fact that Features hasn’t changed much since Drupal 6. My only advice is to get to know the drush Features commands: drush fr (feature revert), drush fu (feature update), et cetera.
Bear in mind that as the timestamp on this post slips further into the past, Drupal 7 will have gotten better and the things written here will be less true. Until then, heed this advice: 1) introduce a healthy time/budget buffer in your Drupal 7 estimates, 2) be prepared for programming challenges, 3) do not expect everything to “just work” like it did in Drupal 6 and 4) use forums, issue queues and IRC to your advantage. The good thing is once you get into developing with Drupal 7, you will realize how much better it is as a framework compared to Drupal 6. My guess is we have about a year to wait before the old, important Drupal 6 modules are fully upgraded, and the community can return to relying on a large canon of feature-rich and largely bug-free modules.