It is desirable to have a default for the argument

Named parameters are perfect in this case. You provide default values at the time you define them.

Before using the command-line argument, you have to evaluate if it was provided in the command line. If not, you have to set the default value at that moment.

The argument is mandatory

You don't have means to determine if the user provided a value for the named parameter.

To know if the user provided a value for the command-line argument, you just get the command-line argument and compare it to a null value.

You need several arguments but it is probable that not all of them are present.

If you don't have a value for a named parameter, you are not forced to enter it when you run the job or transformation.

Let's suppose that you expect three command line arguments. If you have a value only for the third, you still have to provide empty values for the first and the second.

You need several arguments and it is highly probable that all of them are present.

The command line would be too long. It will help explain clearly the purpose of each parameter, but typing the command line would be tedious.

The command-line is simple as you just list the values one after the other. However, there is a risk—you may unintentionally enter the values unordered, which could lead to unexpected results.

You want to use the argument in several places

You can do it, but you must assure that the value will not be overwritten in the middle of the execution.

You can get the command-line argument by using a Get System Info step as many times as you need.

You need to use the value in a place where a variable is needed

Named parameters are ready to be used as Kettle variables.

First, you need to set a variable with the command-line argument value. Usually this requires creating additional transformations to be run before any other job or transformation.