One advantage of "parallel --dry-run" over "xargs echo" is that the former quotes its output:

    $ touch 'Ham
    Jam
    Spam'
    $ touch 'J.R. "Bob" Dobbs'
    $ find . -type f -print0 | parallel -n1 -0 --dry-run echo
    echo ./Ham'
    'Jam'
    'Spam
    echo ./J.R.\ \"Bob\"\ Dobbs
    $ find . -type f -print0 | xargs -n1 -0 echo echo
    echo ./Ham
    Jam
    Spam
    echo ./J.R. "Bob" Dobbs

For my own "dry runs", though, I've always preferred passing the command line to

    #include <stdio.h>
    
    int main(int argc, char* argv[]) {
        char** argp;
        int i;
        printf("argc = %d\n", argc);
        for (i = 0, argp = argv; *argp != 0; ++argp, ++i) {
            printf("argv[%d] = %s\n", i, *argp);
        }
        return 0;
    }

to remove all reasonable doubt.

Why does the parallel example look weird? It put the single quotes in all the wrong places, and completely around Jam. It should have printed

  echo './Ham
  Jam
  Spam'

but your output looks different. As an example of how it should look, try this:

  $ find . -type f -print0 | xargs -n1 -0 perl -e'print "\"$_\" " for (@ARGV)'
  "./Ham
  Jam
  Spam"

Having never used parallel, I still believe parallel was correct.

./Ham' 'Jam' 'Spam

would be identical to ./Ham\nJam\nSpam (if \n were the correct translation to the newline in this case) or './Ham Jam Spam'

This would be identical to what you wrote, but only punts to quotes when it doesn't have a canonical method of representing the character otherwise. The fact that you don't need to explicitly concatenate two strings in the shell may be what's throwing you off?

Interestingly enough, 'Ham\n\nJam\nSpam' becomes

./Ham' '' 'Jam' 'Spam

So parallel is just literally outputting all newlines using quotes. I believe this would be identical, if you analyzed it and saw that two newlines are next to each other:

./Ham'

'Spam' 'Jam

It looks like it's only single-quoting the characters that need it, in his example the newlines.

Quoting is nice. That's better than bash -x debug mode too.

What if your command has a pipe in it? Then putting echo in front won't work, because the command after the pipe is still executed. The dry run option always works, and doesn't require editing the command itself.