History Lesson. We made WPF originally to allow design to get more hands on when it comes to Windows based applications as this was consistent feedback we found from the WinForms world. We produce WPF, and it kind of borrowed similar techniques found from HTML but in a more what we'd call mature fashion (XAML).
We then decided (based off customer feedback) to enable a subset of this vision on x-platform and x-browser machines. As a result we ended up with WPF/E (WPF Everywhere) which was later renamed Silverlight.
WPF vs Silverlight. Easy answer is this, if you want create a solution with x-platform / x-browser reach, then Silverlight is your best bet. The downside is you won't be able to break out of the sandbox imposed within browsers, so if its an application that is happy to live in a hands off the machine it dwells in world, Silverlight can provide you a more than reasonable result (Out Of Browser, Isolated Storage etc do allow you more access to a persons machine than normal).
WPF however is there for deep access, meaning you want to access a USB driver or talk to an alternative technology to .NET etc.. same principles, just deeper unrestricted access.
You can deploy .XBAP solutions which is very similar to Silverlight, but provides a bit deeper in terms of access... think of it as the middle child between WPF and Silverlight.
Going Forward. We are spending cycles ensuring WPF/Silverlight converge more in terms of a uniform API etc, to enable you to graduate up/down the technology experience without having to radically shift your logic. We've got frameworks in place today (ie PRISM/MEF) that will help you here, but we are working hard to bring the two technologies back to parity for you all.
Feedback is always welcome and feel free to follow us on twitter to complain/praise via @teamsilverlight.
Scott Barnes / Rich Platforms Product Manager / Microsoft.