I believe that the general application of this is to prevent possible DoS attacks against the hashing mechanism.
Since GetHashCode() used internally by things like Dictionary<,> , and for "normal" data, the hash values must be well distributed so that hash collisions do not occur "too often". When a hash collision occurs, Dictionary<,> returns to a linear search for all elements with the same hash code.
In a public application, it may be possible for an adversary with knowledge of the hash mechanism to send requests with a large number of lines with identical hash codes, as a result of which a normal O (1) check becomes an O (N) search for any dictionary that added these values.
For web applications, in particular, I believe that things like headers and query string parameters are added to dictionaries for quick access to the application, so such an adversary can send a request with thousands of parameters with colliding hashes, as a result of which the request is significantly more resource intensive than a "normal" request. This enhances the effect of any DoS attempt, allowing attack, even if the attacker has only a relatively modest available bandwidth.
By changing the hash value for AppDomain, it is less likely that an attacker can create strings with colliding hashes, thereby preventing such an attack.
Edit comments for addressing:
While the MSDN article does not mention this, the intent of this parameter is not to provide a means for different AppDomains to create different hash strings, it is a safety feature to prevent a third party from creating many strings with the same hashes.
Prior to .NET 4.5 (or with disabled this option), on the condition that I was doing the same version of .NET that you are, "some string".GetHashCode() on my machine would give the same value that you have. Since the hash mechanism used is simple (and, of course, not a cryptographically secure hash), it is relatively easy to reverse engineer and create multiple lines with the same hashes, and then use them as described above to reinforce the DoS attack.
When the option is enabled, the randomness element is added to the generation of the hash code for the strings, which greatly complicates the attacker's reliable splicing of strings.
The fact that it is per-AppDomain is a by-product of the fact that hash codes have certain required properties, for example. two identical lines have the same hash codes. Thus, AppDomain provides a reasonable border for customization effects, since most applications will work fine if this option is enabled.
This new parameter is most likely to help solve the problems encountered in disclosing this vulnerability: CVE-2011-3414 related to the use of hashing collisions in ASP.NET applications (I believe that the problem was fixed in other versions of .NET, limiting the number of keys that can be provided in the request, preventing the attacker from creating so many collisions that the performance deteriorates significantly). The reference article mentions the lack of randomized string hashing as a factor contributing to the widespread nature of the problem.