The Flash format itself has no notion of animation other than transformation matrices. You can apply a matrix to an element on a per frame basis to move it around. Want to move something across the screen in 3 seconds? Calculate how many frames 3 seconds will take, then calculate the matrixes required for each frame along the way. Oh, and don't forget that the player won't actually maintain any frame rate unless you embed blank audio tracks, so that 3 seconds might turn out to be 2 or 6 or 5, it just depends what kind of mood the machine is in. Silverlight supports the WPF animation model, which is not only time based instead of frame based, but lets you define the start and end conditions and it will figure out how to get there for you. No need to deal with matrixes. No need to calculate positions on various frames. It just works.
Flash stores its shapes using binary shape records. In order to write shape definitions, you will need to either license a 3rd party Flash file format SDK, or build your own. It isn't too difficult, but it does require a bit of a learning curve and the ability to manipulate things at the bit level, since shape records don't align on byte boundaries. Needless to say, it isn't the kind of thing most people can write and have all debugged in one afternoon. Silverlight uses XAML. XAML is text based and can be output using a simple XML object. No need to buy special libraries to write files. No need to write your own libraries. Just stream some text to a file and you're done--easily the type of thing that can be debugged and finished in an afternoon.
Flash stores its fonts glyphs using the same exact shape definitions that are used for any other shape. The player itself does not understand TTF files, so you'll end up digging deep into the Win32 APIs and the fairly vague definitions in the Flash file format documentation to come up with something that sort of does the trick. You'll probably spend ages trying to deal with all the intricacies of fonts, because it turns out that typography is actually fairly complex… and you will have to deal with all those complexities yourself. WPF/E lets you embed true type font information directly into your projects, and download that information with the downloader object. No need to do anything special. No need to handle anything yourself. It just works.
Video / Audio
Flash supports multiple video formats. The latest codec is really high quality and the bandwidth usage is nice. There is one problem though if you are creating a tool that outputs Flash content… the formats it supports aren't really used by anyone else. The original video codec, Sorenson's proprietary H.263 implementation is a mutant version of H.263. The compression follows the spec fairly closely, but there are a bunch of features dropped out and you can't exactly just go find a complete spec on how to build your own encoder. The later codec from On2 puts you in an even worse position. Licensing Sorenson's codec isn't that expensive, but On2 will rape you with fees. They are relying on revenue from licensing the codec used by Flash to revive their $2 a share stock price. It is also a completely proprietary format (where at least the Sorenson one was loosely based on a standard). The audio formats Flash supports are all proprietary, except for ADPCM, which no one uses because of its horrible compression, and MP3, which is decent but dated, and still requires licensing fees and 3rd party conversion libraries. Compare that to the Silverlight story. Silverlight implements industry standard VC-1 codec for video, as well as offering support for WMV and WMA. Just about everyone already has Windows Movie Maker, but if they don't it's not a big deal. Why? Because Microsoft makes available a free Encoder SDK for producing WMA and WMV. So, not only are you using formats that people are more likely to be able to encode themselves, but Microsoft also provides your product with SDKs if you want to do the encoding yourself. The best part about it is that Microsoft doesn't rely on WMA/WMV licensing revenue to keep themselves alive, so not only is it easier to integrate, but it's also cheaper.
You can reuse C# classes from your tool inside your exported content. There is no development environment out there for creating real desktop applications which is based on ActionScript. If you go the Flash route, this means that all your classes and objects have to be written twice. You need .NET classes to handle the author time experience and Flash classes to handle the run-time. If you have server components, once again you need to switch back to .NET and throw out all the classes that the run time is using. For example, let's say you are creating a tool that outputs rich media quizzes. With Silverlight / .NET, the same entity classes you use to deal with results in the player could be reused on the server side. With Flash, you'd have to write all that logic 2x and keep it in sync as your tool changes.
You can create Silverlight content with the same tools you use on a daily basis. Visual Studio.NET is by far the most powerful and most popular IDE. You can potentially have all the code for the server components, the authoring tool components, and the runtime/player components inside the same project. No extra skills required. No needing to hire some special Flash guru to do the graphics junk. Every developer can contribute to every part of your application.