The protection levels of packages come in several different flavors. The idea is that SSIS knows that things like connection strings can contain sensitive information such as passwords. The package itself may contain proprietary information if you are a seller and your product is WhizBangPackage, and you do not want people to see how magic works. For these reasons and more, MS has a concept of how the underlying XML and the entire SSIS package should be written to disk.
EncryptSensitiveWithUserKey is the default value. Everything that can be sensitive is considered sensitive. When the package is saved, VS will use some bits of the original author's Active Directory account to encrypt strings such as connection strings. Even if this connection string uses SSPI and therefore does not have a password, it will still encrypt the connection string in basic XML. When a package starts, SSIS will talk to AD to distinguish between this information. As a rule, everything works well and well, until the author of the original package no longer works with the company, and their AD account is deleted. What we encountered with SQL Server 2005, a package cannot be decrypted using the SQL agent job that runs the package. The developer could go and open the package and it will work normally in interactive mode, but it will not work in non-interactive mode. The immediate resolution was to update the author to someone with an active AD account and reinstall. This may be fixed in the current / future release, but my military history is on that.
DontSaveSenstive is the only parameter I have ever needed. SSIS will not write anything that looks like a password in a .dtsx file when it is saved. And my experience was that after saving in the current development session, he would also disable it, which would lead to immediate verification errors. In particular, this makes the PITA FTP task work if you are not using the configurations that you should as the only normal way to transfer packets between environments. Use the configuration to help SSIS connection managers remember your password without clicking on a disk.
EncryptSensitiveWithPassword Instead of using the AD account to encrypt sensitive bits, you now use the password provided by the developer. The disadvantage of this is a team of more than 1 person, now you have a common password and a password shared by more than one person, the goal of having a password wins.
EncryptAllWithPassword Instead of just encrypting sensitive bits, it encrypts all XML with a password. The same drawback as before, shared a secret = no secret. In addition, if you lose the key, you will hunch over and recreate your package.
EncryptAllWithUserKey The same as with the password, it encrypts the entire file with the AD author account as the key. The same drawback as above, this account is leaving, and there is no key to unlock the package.
ServerStorage - it doesn’t matter what your local parameter is, assuming you are deploying the msdb directory, the packages will be encrypted in the database. I have never used this to be honest. We deploy to msdb, but rely on our configuration to make sensitive, sensitive data.