Probably the most common one is to load assemblies that contain plug-in code from untrusted parties. The code runs in its own AppDomain, isolating the application.
Also, it's not possible to unload a particular assembly, but you can unload AppDomains.
For the full rundown, Chris Brumme had a massive blog entry on this:
If you create an application that allows 3rd-party plug-ins, you can load those plug-ins in a separate AppDomain so that your main application is safe from unknown code.
ASP.NET also uses separate AppDomains for each web application within a single worker process.
App Domains are great for application stability.
By having your application consist of a central process, which then spawns out "features" in separate appdomains, you can can prevent a global crash should one of them misbehave.
As I understand it AppDomain's are designed to allow the hosting entity (OS, DB, Server etc...) the freedom to run multiple applications within a single CLR instance or each program in its own. So its an issue for the host rather than the application developer.
This compares favourably with Java where you always have 1 JVM per application, often resulting in many instances of the JVM running side by side with duplicated resources.
I think the main motivation for having AppDomains is that the CLR designers wanted a way of isolating managed code without incurring the performance overhead of multiple Windows processes. Had the CLR been originally implemented on top of UNIX (where creating multiple processes is significantly less expensive), AppDomains may never have been invented.
Also, while managed plug-in architectures in 3rd party apps is definitely a good use of AppDomains, the bigger reason they exist is for well-known hosts like SQL Server 2005 and ASP.NET. For example, an ASP.NET hosting provider can offer a shared hosting solution that supports multiple sites from multiple customers all on the same box running under a single Windows process.
Another benefit of AppDomains (as you mentioned in your question) is code that you load into it can run with different security permissions. For example, I wrote an app that dynamically loaded DLLs. I was an instructor and these were student DLLs I was loading. I didn't want some disgruntled student to wipe out my hard drive or corrupt my registry, so I loaded the code from their DLLs into a separate AppDomain that didn't have file IO permissions or registry editing permissions or even permissions to display new windows (it actually only had execute permissions).
When 10 users browse a page say (login.aspx) in a published website, ASP.Net Worker Process (w3wp.exe) creates 10 application domains to host the page assembly into it for each client, thus creates 10 appDomains. so you need to understand first what is the appdomains i was searching for this topic and i found this blog post http://blog.flair-systems.com/2010/05/c-fastfood-what-appdomain.html i think it will be useful for you