Question 1. The xap file must be accessible by the end user, and therefore I don't think you can stop an authenticated user from getting it from the server. And even if it isn't available, the user can find it in their browser cache.
Question 2a. Yes, the user can decompile the xap. It is just a zip file. Rename to zip, extract the contents, view with Reflector etc. Have a play around with Silverlight Spy and you can also see some interesting stuff. You can use an obfuscation tool on your assemblies, which is a useful deterrent, but even that could be decompiled by someone with sufficient resources / energy.
Question 2b. I think it would be possible to see 'information passing between modules', as a Silverlight app can be debugged using WinDbg. Once again, obfuscation will at least help deter casual introspection.
Question 3. Yes, web.config should be safe, unless you go out of your way to expose it.
Question 4. SSL won't prevent any of the introspection issues on the xap file listed above, but will stop people sniffing the traffic. The only problem you will have is how to mitigate a man in the middle attack (where a proxy substitutes in its own certificate). There are ways to mitigate this but I don't know the best practice off the top of my head.
Based on the questions you have asked, here is a risk you should mitigate. Imagine the user connects to your SL app, logs in, then you fetch their 'roles' from the server. If they had decompiled your xap, and figured out they need to be in the 'admin' role to open up access to everything, they could put a proxy in-between the SL app and your server and modify the responses so that the SL app thinks they are in the 'admin' role. This is a man in the middle attack where the end user is trying to hack the system. Even if you are using SSL this is possible, because the proxy will use its own certificate and the end user can add the proxy's certificate into their trusted certificates store.
I have never been able to properly solve the above risk on the client side. I have made it difficult for a hacker by using obfuscation, and adding a custom header to the requests/responses which was effectively a checksum with a hidden private key to encrypt the checksum. However if the end user managed to de-obfuscate / decompile the xap, they would theoretically be able to find the private key and see my encryption algorithm, and therefore be able to substitute in a new checksum after altering the 'role' in the above example.
In summary, I have concluded it is impossible to properly secure the client side. And if you deem the risk sufficient, it is best to duplicate the authorization on the server.
For example, if it is a requirement that a user must be in the 'admin' role to view 'customers', then I will display the 'customers' screen on the client if the user is in the 'admin' role. However, on the server, when the SL client calls the service to fetch the 'customers' data, I also check the current authenticated user has permission to see the data (as opposed to see the screen).