A convenção normal é que os argumentos sempre seguem as opções. A primeira não opção (a primeira cadeia na linha de comando que não inicia com - ) termina as opções e inicia os argumentos.
Algumas ferramentas, principalmente as ferramentas de compilação (compiladores, linkers), sempre foram contra essa convenção. Outro exemplo que você nota é find . Às vezes isso é feito porque as opções entram em vigor no ponto da linha de comando em que aparecem, portanto, é necessário especificar os argumentos antes e depois da opção, onde a opção se aplica a esse argumento apenas se o argumento aparecer após a opção .
Esta convenção permite que você escreva um script de shell que contenha uma linha como esta:
rm foobar ${more_things_to_remove}
... e garanta que você não pode adicionar opções ao comando rm acidentalmente, mesmo que a variável more_things_to_remove da shell tenha um valor desagradável como " -rf ".
Essa convenção é anterior à convenção mais recente de usar a opção especial -- para finalizar o processamento da opção. -- é uma maneira muito melhor de marcar o fim das opções explicitamente:
rm -- foobar ${more_things_to_remove}
# and it works even if you don't need to delete something called "foobar":
rm -- ${more_things_to_remove}
-- forçando o fim das opções) mesmo que eles não tenham nenhuma razão especial para quebrar a convenção como compiladores e algumas outras ferramentas fizeram.
Pessoalmente eu nunca sei quais utilitários ainda aderem à convenção e quais não, então eu sempre coloco as opções antes dos argumentos como antes, e fico levemente surpreso quando vejo o código de trabalho de outra pessoa que faz isso na ordem oposta!