The metadata API and the "change set" feature are not "destructive" by nature. Many people think that when you copy a profile, you are copying all of the permissions for that profile, including all object and field permissions. However, this simply isn't true. While you do need to compare base profiles for a comparison of, for example, "API Enabled" or "Export Data", objects and fields are enabled separately by default, which means that you can copy just a subset of all available permissions without worrying about a complete overwrite.
It is true that you should be wary about using profiles in the Eclipse IDE, and with good reason. The plugin is "smart" and tries to only deploy changes. This means that in order to deploy a change to a field level security item, you have to modify both the profile and the custom field in order for a change to occur. This is usually a huge hassle, and so you should probably avoid doing that.
Change sets, and the metadata toolkit, however, are perfect ways to copy just the permissions you want to copy. This is because the system will only change the settings relevant to the combination of profiles and fields/objects. The Metadata Toolkit gives you the flexibility of editing raw XML files, allowing you to copy only the information you want to.
Let's take a look at using the Metadata Toolkit, since it's fairly easy to use, and has reasonable documentation.
First, I create a package.xml file that has the following content:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Lead.CurrentGenerators__c</members>
<name>CustomField</name>
</types>
<types>
<members>Admin</members>
<name>Profile</name>
</types>
<version>29.0</version>
</Package>
Here, I specifically request a single field and a single profile. The results of this export gives me:
objects/Lead.object
<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<fields>
<fullName>CurrentGenerators__c</fullName>
<externalId>false</externalId>
<label>Current Generator(s)</label>
<length>100</length>
<required>false</required>
<trackFeedHistory>false</trackFeedHistory>
<type>Text</type>
<unique>false</unique>
</fields>
</CustomObject>
profiles/Admin.profile
<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
<fieldPermissions>
<editable>true</editable>
<field>Lead.CurrentGenerators__c</field>
<readable>true</readable>
</fieldPermissions>
<userLicense>Salesforce</userLicense>
</Profile>
If I change "editable" to false, and deploy this change to another organization with the same field (or, even if the field does not exist), then the only change that would occur is that the single field level security setting would change-- all other fields, objects, and other permissions would remain intact.
This feature is often used to deploy security changes that are scoped out in a Sandbox. You can be as selective as you'd like to be, even down to just a single field's permissions. In this manner, you can choose which permissions you'd like to deploy. Also, you could choose to manually edit the XML files before deployment to deploy different sets of field level security permissions within the same package. They do not need to be a fully rectangular matrix. For example, you could build a deployment like this:
Field 1 Field 2 Field 3
Profile 1 Edit - Read
Profile 2 Read Edit -
Profile 3 Edit Edit Edit
In this case, two field level security settings will not change (Profile 1's Field 2 security, and Profile 2's Field 3 security), while the other settings will be as specified. Hopefully this answer will help clear up the confusion of the other answers that have been posted to this question.
TL;DR version
Only settings explicitly mentioned in a change set or metadata API xml file will be modified. One should not think of this as an "overwrite", but instead a "selective edit."
Best Answer
You can absolutely deploy profiles and permission sets safely, provided you keep a few things in your mind:
1) Profiles work like junction objects when retrieving them from salesforce. In other words, if you ask for the Admin profile and include Account and Opportunity in the retrieve, the Admin profile XML will contain ObjectPermissions, FLS, RecordType Visibility for these two objects and UserPermissions only. No Class Access, Page Access etc because you did not request them in the retrieve. So... if you migrate this Profile XML over, obviously you will not get desired results.
2) Profiles merge on the server. In other words, if you have Object Permission for X set to RWD and you migrate the updated Object Permission for X, it will override existing permissions. But, as part of that migration, if you add Object Permission for Y, it will be added on as well.
3) Profiles are never created in Salesforce. Let me clarify... they are never created; they are cloned and then overridden. So, if you are creating a Profile using the API, you are essentially cloning the PlatformUser profile or StandardUser profile (depending on license type) and then overriding it. There might be artifacts of that Profile in your new Profile.
4) Some Profile sections, like AppVisibility and TabVisibility indicate negative values by absence. This is the most dangerous aspect of Profiles that deserves most scrutiny. Try this: Retrieve the profile XML along with CustomTabs. Back that up. Now, change the TabVisibility for your favorite tab to Hidden. Now, re-retrieve your XML. Execute a compare between your Profile XML. You will see that the TabVisibility is missing in your second retrieve. So, if you migrate that to another Org (sandbox or production), you are not going to turn off the Tab as expected because the XML is missing (remember that Profile XML merge).
As long as these basic rules are kept in mind, you are absolutely ready to migrate profiles or permsets anywhere you want. It seems daunting but it is not that bad.
Contact me if you want more info or talk a bit more about this: sridhar at dreamfactory dot com (Warning: We make the SnapShot Change and Release Management tool so you might get a 2 min sales pitch when you call me :-) ).
Good luck!