I saw this question on the Salesforce StackExchange and thought it would be good to clarify why 'standard' profiles are immutable:
"Why does salesforce not allow us to change the permissions of standard profiles to standard objects? I know the workaround to use is to clone that standard profile into a custom one, but it seems like a pretty random limitation to impose."Profiles are an extension of licensing in salesforce.com. Licenses enforce access and define the maximum allowed permissions for a user. Profiles are actually the glue that connects licenses and users together. Every time you create a user, you specify a license and then assign a profile from a picklist that only includes profiles that share the same license. Under the covers, a profile is actually the middle object between user and license.
Every time a license is added to an org, we automatically create one or more 'standard' profiles with immutable user and object permissions. You'll notice that other things on 'standard' profiles can be changed like assigned apps, tab settings, and record types.
A best practice for customers with the ability to create 'custom' profiles is to use these 'standard' profiles as templates in order to clone and create their own. In some editions where custom profiles are not allowed, assigning 'standard' profiles is the only way to provide access for users. Check out this blog posting to understand more about this best practice.
The 'standard' profiles are also considered managed just as components in an appexchange package are managed by an ISV (Independent Software Vendor). 'Custom' profiles, similar to any other customization in your org that you create, are considered not managed and have special rules that protect them from being changed during a release cycle.
From release to release, we may add an object or a new set of functionality that we want to license differently. A full CRM salesforce license may get access automatically to some new sales feature whereas the platform license may not.
When we upgrade our code during the release, we may allow and enable access to these objects and new features through object and user permissions on 'standard' profiles. But you'll notice that we almost never change your 'custom' profiles. This enables easier transition through our release process since you can choose whether to include access to these new objects or new features in your own 'custom' profiles.
Another reason why we will enable certain objects or user permissions in the 'standard' profiles is that they are used in group and professional editions where there is no ability to clone or customize a profile and you wouldn't get access to new features or objects unless we enabled permissions automatically on our 'standard' profiles.
There are many reasons why 'standard' profiles are immutable and I hope this blog posting helps illuminate why.