I'm in week 5 of teaching my Visual Basic I programming class at the University of California San Diego Extension. The week 5 class is going to focus in on WPF and helping students get a better feel for working with this new user interface paradigm, and it's custom 'script' language XAML. :-)
WPF comes with several new concepts and I think that for developers who are just getting started and or coming from a solid web application background many of these concepts feel very natural. On the other hand there are a host of developers out there who are coming from a Forms/Win32 based background. For these developers, even though most people think of WPF as a Forms replacement the new declarative model and in particular the new buzzwords leave them overwhelmed.
After all most people that show of WPF applications are busy making sure they've included as many graphical elements as they possibly can, for example one famous paraphrase of Tim Huckaby is "It's just not a WPF application without some form of gratouitous animation."
However, from my standpoint, in the way I approach introducing developers is to explain some elements on XAML and then focus on the similarities between WPF and Windows Forms development. For example in Chapter 17 of the soon to be released Professional Visual Basic 2008 which will ship this May, my approach is to literally have you start by designing what could easily be a Windows Forms application using WPF. Over the course of the chapter the application is migrated with the title bar being hidden, buttons being customized, etc as you introduce more and more concepts that are native to WPF.
In the beginning you start by working with the Visual Studio 2008 editor. This editor is well known to be VERY limited in comparison to Blend. However, if you are moving from Windows Forms to WPF then you'll feel much more comfortable in this environment. Start here and work towards the same type of applications, then introduce Blend. Blend not only provides several key examples that you can use to get a better feel for the WPF paradigm, but allows you to start to take that item which you feel comfortable with and migrate it to a WPF paradigm with routed events, complex styling and other elements that are much more in keeping with the declarative programming model. Of course this book isn't about WPF so I don't go deep on things like styling and databinding and other topics, but it will help you start so that those topics combined with everything else in WPF aren't quite so overwhelming.
Keep in mind that while there are rumored to be several WPF related updates coming in the next update to Visual Studio 2008 (I think I covered when to expect that to appear) even with these updates you as a developer are still going to need to start to transition to this new UI paradigm. Fortunately because WPF performs better on Vista then on XP, and has no backward compatability below XP there is still time for you to get up to speed... but that grace period won't last forever. More importantly those performance issues are primarily for heavy duty graphics, if you are working in a more Windows Forms paradigm you won't see much of a difference at all.
Which brings me to "Why do it now?" - Well we already have an announcement that Windows Forms 2.0 was the last of the new development on that model. By starting to work with WPF now, even though you might not create a gratouitous graphic, you are creating an application tier that as WPF takes over (and with it's relationship to Silverlight 2.0 the pace of adoption is imho going to accelerate) your code even though it still has the standard Windows Forms look will integrate and be able to be adapted much easier then people who are continuing to create new solutions using Windows Forms. So now is the time to take those existing designs and just start by implementing them in WPF with little or no leverage of the high end graphics - and then as you get more comfortable with just how much power WPF provides you can update them to leverage that power.
