For me, package configurations all boil down to one thing - portability...

Basically if you have an environment where some level of change control is enforced, package configurations become sort of a not negotiable, wether you go for SQL or XML configurations.

Consider:

You are developing on your local C drive pointing to your local SQL server, or perhaps even a mapped network drive.

Now you need to deploy your package to a different machine where the job will be tested. For you to do this without package configurations, you would now have to manually go and update the package to point to the new drive letters.

After testing, your job needs to be productionalised. Once more you would need to change some settings to do this.

Why not simply have package configurations take care of all of this for you, have a configuration per environment. As an added bonus, once you have created a configuration, you can reuse it in multiple places provided you have the same naming conventions (which is a bonus as you now align to some kind of standard).

Some of the other benefits include for example when a setting changes. For example, what if a FTP site changes IP address? Are you going to go and change every package manually? Why not change it within your configuration and all your packages adjust automatically...

Good luck though, getting the understanding of Configurations going takes a while and a whole lot of discipline.

~PD