Of course you can, in fact, the general point XML (and by extension the REST architecture) and XHTML is to allow data (which is often served by a webserver), to be effectively used by a client application.
It depends how fine-grained you want to have access to the general execution engine. If you're fine with users downloading the code that runs, then goahead with REST and XML data transfer. If you need your inner workings to be secret (such as in Google Apps)
or for lots of small massive-data bindings, you might need your app to basically be a front-end on a webserver elsewhere.
Nonsense. If you mean developers interacting on the same project that is nonsense, that is what software engineering and source control systems are for, and I don't see any real advantage to web applications in this collaboration. If you are talking about end
users interacting, I don't see any advantage either in this regard, except perhaps the simple nature of developing HTML pages which is not transfered over to Flash or Silverlight development.
I mean end-users, not developers. I see no need for development to migrate to a web-based platform at this time.
You seem close to conceding there that HTML pages do allow for collaboration through use of appropriate web-technologies, and Flash and Silverlight are designed to complement, rather than replace this.
Flash itself has suffered from many vulnerabilities and it's existence on your machine decreases the overall security of the system. .NET is not exactly immune to vulnerabilities but it does have some pretty fine grained access control via application domains.
Well, that's Flash's problem. No (currently released) system is immune to vunerabilities, and while I'm sure the .NET framework is no exception, their reliance on managed code rather than pseudo-byte code means that while it is easy to "crash" the app, the
potential for you to do Bad Things through security vunerabilities is very much lessened.