Today's phone wars are essentially another flavor of the old Browser wars, or the old decision of "windows vs. web"...which technology to use.
Your question and profile tells me you are more familiar with the Microsoft stack, so I will keep my answer directed that way. I'm sure the non-microsoft folks will have their own bits of wisdom they can add as well.
For Phone apps, user experience is key. However, using the philosophy of write once, run everywhere, you may get in trouble. One development technology that you use that may look/run great on one platform, may be non-existent for another (you hit it above regarding Silverlight for non-windows phones and flash for iPhone)
Here are some different platform options:
Android - for those in the .NET world who want to develop for Android, Mono seems to be the best way to go if you want it to run specifically for Android.
iPhone - MonoTouch is the way to go for iPhone at this point. They are both currently owned by Novel, but are licences differently. The main difference is that they MonoTouch apps are compiled down to machine code targeted for iPhone.
Windows Phone - Your best user experience here would be, as you mentioned, Silverlight.
Blackberry - even Blackberry has come out with some development tools directed at the .NET developer. Once again, these would work best with Blackberry, but the cross platform options are minimal here too.
Bottom line - In my opinion, you have two ways to go here:
First, you can create an architecture where you have your middle tiers and back end common using POCO objects - hosting this in the cloud. You can then direct the user to a different user interface when you detect the platform that is hitting your site. This would present the optimal experience for the user depending on the platform they are using. The bad thing is that you will be creating multiple different user interfaces. Using some standard patterns - this is do-able, but will make it more difficult to debug and maintain. This is the kind of architecture Miguel de Icaza was envisioning when architecting Mono.