Every project is different, so it makes sense to revisit the available tools and select the right one for the job. Here's the landscape as I see it. But first...

Guiding Principal: Keep it simple!

I think this should be everyone's starting position, but it's important to reiterate the importance of keeping things as simple as possible - both for you as a developer and for the end users. Adding in extra "stuff" is not a good idea. Take a read through "Getting Real" by the 37Signals team. They are all about building less, and keeping things simple. This is a major "Web 2.0" idea - keep a tight reign on features - make them prove their worth before letting them into the app.

With that in mind, here's how I look at things...

1) Can I use Google Maps or Virtual Earth?

Since the general public is most familiar with these systems, it makes sense to build on them if you can. Sure there are licensing/advertising issues, but that's to be expected - there is no free lunch when it comes to high-resolution global data sets.

The thing I look at next is data - can the problem be solved with push-pins? If so, we'd write custom data services against a SQL table with Lat/Lon columns. This is blazing fast, and a great solution if it works for your problem.

For non-point data, I'd see if we are talking about lots of features or just a few at a time. If it's just a few at a time, we can send them as geometry (GeoJSON etc) otherwise we'll need a rendering engine to create images, and I'd look at using ArcGIS Server (9.3!) or GeoServer (which incidentally now has support for SQL Server 2008). You can create tile caches, or (with Google) dynamically render a layer. Since the UI and server calls are all under your control, the sky is the limit in terms of what you can do.

2) Can I use OpenLayers?

Even if you are using the ESRI platform, OpenLayers is still a compelling front-end. It can natively consume other WMS/WMS Cache services, GeoRSS, GeoJSON, and a whole host of other things. It has vector editing tools, and support for WFS-T if you have a back-end server that speaks that dialect. It is also open source, has a mountain of unit tests, and is pretty easy to develop with. I'd expect to see someone write extensions for this that can consume layers and features from the ESRI REST API.

3) Can I use the ESRI Javascript API?

If you don't need to pull in non-ESRI external data, then the ESRI Javascript API is pretty compelling. The ArcGIS Online tile caches make for a good starting point, and the map control itself is very nice to work with. To do anything complex, you'll need to get serious with the Dojo Toolkit, but that's worth it regardless of the map canvas you choose. The REST back-end is pretty smooth for simple apps, and when things get more complex, you can always roll your own services (you can read more about that here.)

4) Must I use the WebADF?

Although 9.3 has led to some performance increases, the API is still a huge maze. I think that the breadth of knowledge required to get started with the javascript options often scare off developers. From our experience, while the initial learning curve for the javascript options may seem higher, the effort of developing and debugging even a moderately complex WebADF application vastly exceeds learning  javascript, Dojo/jQuery/ExtJs/YUI, the zen of REST, miscellaneous "HTTP Goodness" and JSON Web Services.

Developing complex sites any any platform is complex, and I'd argue that at least with the javascript options you can "see" everything that's going on (although this has *improved* with 9.3), and have much more control over the UI and service tiers.  Some may disagree with me on that, but that's how I see it. I'm sure you can build a high-performance, user friendly, rock-solid application on the WebADF, but I have not seen such a thing (send Urls if you know of any).

Conclusion...

Keep an open mind, and accept that to build compelling Web 2.0 app, you are going to get some javascript on your shirt. Use some good tooling (Aptana or Visual Studio have reasonable to good javascript support) and it's just not that daunting. Whatever you do, do not pick a technology because it's easier to "get started" with. Look at the longer term, and accept that you'll have to gain some new skills - it's actually pretty fun

Hey - What about Flash/Flex/Silverlight?

Honestly, I'm just not a Flash/Flex/Silverlight kinda guy - while these technologies can do some compelling things, I'm just not "feeling" it. With the performance increases in Javascript (John Resig compares V8 and TraceMonkey - the "guts" of the newer javascript engines), and the large community of developers working on jQuery, Dojo, YUI, ExtJs and other frameworks, I just don't see a need to graft a client-control into the page. This is not to say you should not do this - if you like it / need it, go for it!