The only criticism I have, and this is common to a LOT of technical articles, is that this does not consider the scenario that you have to deploy an package to an environment you have no control over and know nothing of at design time, or if you have configuration values that need to be set as install time. Having faced exactly this problem where we need to deploy packages to customer sites (often the deployment is done by the customer themselves, or sometimes by one of our 'consultants', none of whom have the first idea how SSIS works) we opted for the command line option because it allows us to be a bit more intelligent. We have to supply both 2005 and 2008 versions of our package because our systems support both and with command line installation we can determine the version of the SQL server automatically and deploy the appropriate package. We can also determine the compatibility level of the target DB which is useful because we use some CLR functions and the number of people who upgrade a SQL 2000 DB and leave the compatibility level at 80, thus rendering CLR functions inoperable, is depressing.

Sadly the greatest limitation is the inability of the dtsinstall tool to specify config values as part of the install command meaning that users have to manually edit config values during installation which is very annoying (incidentally, if anyone know of a way to do this I'd love to hear it!).