"So, each player gets six cards, except for the dealer, uh, the player on the dealer's right, who, uh, gets seven."
"On the right?"
"Yes. The second card is turned up, except on Tuesdays"
"On Tuesday..."
"Mm-hmm.  Oh, look what you got - two jacks!  You got a half FizzBin already."
"Heh-heh... I need another jack!"
"No, no, if you got another jack, why you'd have, uh, a shralk."
"A shralk?"
"Yes, you'd be disqualified."
"Oh"
"No, what you need now is either a king and a deuce - except at night, of course, when you'd need a queen and a four"

- Star Trek episode #46, where Kirk and Spock explain WPF

I've spent much of the past year working pretty intensively with WPF (and other technologies), working through all the major published references, posting demos to community sites, and occassionally presenting at meetings of the local .Net User's Group.  WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.

• Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively?  I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
• Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
• Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether?  Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
• Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
• Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months? 

This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice.  Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache.  Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.

Here are some considerations I'd suggest are important, to avoid making a big mess with WPF...

• Embrace Xaml  If you're writing code-behind to define more than the tiniest fraction of your layout, to quote Mae West, "you're not doin' it cor-rectly!"  Xaml was invented for a reason.  It makes it easy to switch styles, support designer tooling, and often simplifies the implementation to an almost unimaginable degree, but I constantly see developers writing large volumes of code when they should be writing a tiny amount of markup.  Here, for example, is something that amazes alot of people; a fully-functional WatermarkTextbox implemented using just 3 lines of Xaml, leveraging the BooleanToVisibilityConverter provided by WPF.

<Grid Background="{StaticResource brushWatermarkBackground}" >
   <TextBlock Margin="5,2" Text="Type something..." Foreground="{StaticResource brushForeground}"
              Visibility="{Binding ElementName=txtUserEntry, Path=Text.IsEmpty,
              Converter={StaticResource BooleanToVisibilityConverter}}" />
   <TextBox Name="txtUserEntry" Background="Transparent" BorderBrush="{StaticResource brushBorder}" />
</Grid>

There are some exceptions, especially when it comes to animation and setting DataContext but, in general, layout = markup, and you usually should not need to resort to code-behind just to set control properties.

• REALLY Embrace Xaml!  If you're excited that VStudio sp#1 now features an "event" button, and you're waiting for point-and-click support to cover all the essential WPF features you will use regularly on actual projects (DataTemples, for example)... good luck!  It only takes a few weeks to become completely comfortable with direct manipulation of Xaml, and this is infinitely faster than searching through property lists, and results in much more succinct, maintainable mark up.

• Rely on DataTemplates  This is another area where even some very experienced developers seem to completely miss the point.  Just the other day, I watched a presenter's WPF demo include newing of ListItems in code-behind, with object references attached through the "Tag" field.  As many WPF authors have emphasized, WPF supports a true "data centric" implementation model, enabling you to do things like simply bind a high-level container directly to a collection of objects, defining a DataTemplate to specify the visual representation an object of that type should take when it appears in the list.  Otherwise, you end up using WPF to write Windows Forms code. 

• Go Easy With Custom Control Templates  Many published WPF resources and online tutorials focus heavily on the ability to replace the appearance of any control, simply by defining an alternative ControlTemplate.  Unfortunately, this can lead developers to whip up new templates for things as simple as a request for a ListBox with rounded corners, when they could simply center a ListBox with a Transparent background over a rounded Rectangle.  The volume and complexity of markup in many of the standard control templates (along with accompanying color and component definitions), is non-trivial, and trying to maintain edited local copies of more than a few could grow to become a problem.

• Learn Blend - but REFACTOR ITS OUTPUT!   Animation and other visual effects can often really only effectively be designed using a tool like Expression Blend.  Unfortunately, Blend's simple point-and-click interface encourages generation of massive amounts of convoluted Xaml, which must be refactored early and often if you expect to have any hope of maintaining the source.  Members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity separate -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" project source, rather than allowing designers and developers operate directly on a single shared code base.

MS User Experience Team UK - Lessons learned in teaming devs and designers on actual WPF projects

Billy Hollis demos a very nice UI, discussing design/dev. lessons learned on an actual WPF project

• It Really is REQUIRED Reading   I believe that someone else in the developer community has already stated that WPF makes it much easier to generate a more hopeless mess far faster than was ever possible using any previous Windows development technology.  In order to make any sense of the pros and cons associated with the array of implementation choices, I recommend that you start by reading Nathan cover-to-cover (things seem to start making sense around the third reading), work your way through Sells, MacDonald, and Anderson, and keep a copy of Petzold on hand as a reference of last resort.  As always, even the most definitive resource was out of date on the day it was published, and you must monitor online feeds for the latest information on feature changes, best practice recommendations, and working implementations you can simply borrow.

Update (9/22/08):  I laughed out loud when I first came accross the title "Teach Yourself WPF in 24 Hours" in a bookstore recently, but I found this to be an AMAZINGLY good book!  It covers all the major areas of WPF succinctly and clearly, using non-trivial examples that are applicable to real-world projects, and even manages to sqeeze in mention of architecture and process issues that are usually ignored.  I had some minor quibbles with some of the material, including the decision to use the MVP (Model-View-Presenter) pattern in all of the examples, but its still an excellent book.  Don't get me wrong.  You absolutely can NOT learn WPF in 24 hours, but you CAN get an excellent introduction to WPF concepts and techniques in the three to four days it will take you to get through this material, and I highly recommend that you start here, even if you've already had some exposure to the framework.