'a lot' is not the same as 'exactly the same'.
Right. the biggest deviation from the rule that "WPF is a superset of Silverlight" is that Silverlight has the Visual State Manager.
Microsoft's position (or a least what Scott Guthrie says) is that Microsoft is working to keep the two synched - some new features will appear first in Silverlight, some in WPF, depending on release schedules. Visual State Manager will be in the next release of WPF (with .Net 4.0, probably by end 2009).
if Silverlight does all WPF does
It will never do that, for 2 reasons.
1) Size - WPF is the UI end of the .Net iceberg. The full .Net framework (including WPF) will never begin to fit in the 5Mb or so for the silverlight download. e.g. Silverlight has no way to connect to Databases across the network - just to Web services in SOAP, XML or JSON.
2) Security - Silverlight apps are not trusted to do things like read and write all of the file system, unrestricted access to network, printer, keyboard etc that a fully trusted .Net app has.
Now, if Silverlight can't do some of the things a WPF app can then I'm not sure I need Silverlight - Flash is much more widespread
that's your choice, and many people will choose the same. Others will choose otherwise. Some code can be shared between Silverlight and regular .net apps, and the same skills and tools apply.