A company may wish to migrate an existing application to WPF to add a new
look to the application, or, if the application was an intensely graphical
one, to increase performance.

Architecturally, WPF applications and Windows Forms applications only have
about one thing in common, Databinding. Otherwise chalk and cheese is a good
analogy.

If you are starting a new application, I not wish to discourage you from a
WPF app but in my opinion the tools available for creating WPF applications
as well as the support from third-party suppliers for components and so on
is pretty poor at the moment. Having actually tried to create an industrial
strength application in WPF I found that it lacked the facilities I needed
and so went for CAB / Windows Forms solution with some WPF content hosted on
Windows Forms.

Personally, given the amount that Visual Studio 2008 crashes and the fact
that Blend 2.0 still isn't available I would hold off of starting any
serious project on a WPF platform and look at it as a learning thing.

If you need to deliver an application in a short time with good features and
support, go for a Windows Forms application while paying close attention to
your data model so that migration to WPF eventually is painless.

I'm a huge fan of WPF, so I'll throw out my impressions of it:
The primary advantage to it is that it doesn't sit on GDI like WinForms, so
you've got a vector-based UI that supports virtually any resolution, is
accelerated by the 3D card (GDI is accelerated but not to the extent that
vector-based systems can). It's a very declarative tech where most of the UI
eye candy is written on the page by the designer independent of the coder.
Also, the databinding is done in such a way that if you connect the property
of one control with another via an event handler (i.e. declare that the color
of a control's background is Blue if myButton.IsPressed, your control's
background will change to blue when pressed (and back to its original color
once the condition is false)...all the magic of DependencyProperty. This
means a TON of stuff that would have traditionally required writing event
handlers and having several code paths for buttons, etc., is all done inside
the WPF code automatically.  This is also true for asynchronous databinding.
In a nutshell, if you say "IsAsynchronous=true" for your datasource
declaration, the dependency property it's bound to listens for the
OnDataBindComplete(or something like that...can't recall it right now), and
automatically updates from the proper thread while maintaining responsiveness.
And from a flexibility standpoint, its styling facilities are a radical
departure from WinForms. WPF apps have a logical tree (of buttons, grids,
etc) that have no inherent look to them; they just have functionality (a
button can be pressed, grid can hold stuff, a textbox has a Text property).
But they can look like whatever you want to define their template as. So for
example, if you want to draw a tab control, you could implement it as a radio
button group where each tab is a radiobutton because a tab control logically
functions like a radio button group.