I have been working on a Silverlight project, and the experience of using it for a period of several weeks on a real application has been quite good. I thought I would highlight three aspects that made it good.
1: It has real C# and .Net inside.
The CLR used in Silverlight may be cut-down, but the developer experience isn't. We used Visual Studio 2008, ReSharper, and all the good parts of C# 3.5: generics, extension methods, Lambda expressions and LINQ.
There is no LINQ to SQL or EF or database drivers -all data from servers comes over web services, but there is LINQ to objects and to XML.
There are even third party add-ins. We used the NInject IOC container. Other IOC containers like Unity also support Silverlight now. There are also Extensions and testing tools, and mocking frameworks are getting there.
The code-run-fix cycle in Silverlight is very quick, giving immediate feedback on what your code changes have actually accomplished. I think we produced that application faster than a similar website could have been done.
2: XAML
XAML is the UI mark-up language used in Silverlight. It's also used in WPF, which is Silverlight's older brother and the successor to Windows Forms.
It's very good: all .Net coders should know the basics to XAML, unless you want to only ever work in ASP.Net. I'll rave about XAML at length given the chance, despite only being a novice. Despite its power and depth, the basics are easy to grasp. Simple Windows Forms style interfaces are easy in XAML, and it will give you room to do much more if you need to. The look and feel of the application can be set or changed in styles, and the data binding support is so good that it generally becomes a key part of a Silverlight or WPF application.
XAML encourages a separation between functionality and visual style, so that parts of the application can be handed back and forth between designer and developer as needed.
Compared to a web app where cross-browser issues are common, a Silverlight application looks the same between browsers, and even on an Apple Mac. The cross-browser issues that we had were few, and generally around integrating with the browser, or the machine's installed fonts. Compared to a desktop application, the installation is basically non-existent and the security implications lesser.
3: Developers
There is a perception that Microsoft's strategy in "taking on Flash" is to leverage the popularity of C# and get an army of low-level C# developers doing Silverlight. That perception is false in at least one respect - the Silverlight developers that I worked with were not low-level. Take a look at the ViewModel pattern that served us well.
I'm sure that you can do "put the data access code in the button-click handler" development in Silverlight if you wanted to, but the environment is rich enough to allow a lot of other ways of working that are more appropriate for larger applications.
.. and also Silverlight 3, which is now in beta, is building on these strengths.