@sync doesn't do that.
If you run 10 external commands then they'll always be run one after another, whether or not you use @sync.
@sync is only relevant if you are mixing internal and external commands. In the current version of Opus, if you don't put @sync before external commands then they may be run in parallel with internal commands, but none of the examples in this thread use any internal commands so @sync isn't relevant here.
It's looking like the next version of Opus will finally make @sync the default so that you no longer need it. I think this will be far more sensible as people generally expect a list of commands to be run in series.
{destpath$} path will turn into the destination file display's path, if there is a destination file display. If there isn't one then {destpath$} will cause you to be prompted for a destination directory that the function will work with. Because of the $ at the end the {destpath$} code means "NEED destination path".
If you use {destpath} ("WANT destination path") instead then it will turn into the destination path if there is one and into an empty string if there isn't one, without prompting you.
You must have had another lister window open. Source and destination are not restricted to the two sides of a dual-display lister. If you have two single-display lister windows open then one will be a source and the other a destination. There's a video in the Tutorials section which expains how all of this works:
[Working with multiple Opus windows/listers (video tutorial))
It might be as a result of using "dopusrt /cmd" before your Go commands. If you're using Opus 9 you should remove the "dopusrt /cmd" stuff and, at least until the next version, prefix all external command lines with @sync if you are mixing external commands (e.g. lame.exe) with internal commands (e.g. Go).