I too was perplexed, but the main use case seems to be when you want to share a particular configuration or need to be sure that you always use the same set of flags:

> Flags are ephemeral – you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability. Filenames solve both: the program describes itself, requires zero setup, and any configuration can be shared by simply renaming the file.

[Emphasis added] Although I find a script that wraps the command and calls it more versatile, there might be some value in this idea for some very simple cases, like example #4.

I suppose scripts are OS specific (mainly Windows and "everything else", because #/bin/sh is everywhere else).

That said, apparently there's cursed methods of having a universal shell/batch file of sorts, according to https://stackoverflow.com/questions/17510688/single-script-t....

Anyway, I'd argue for the vast majority of cases, a shell script that wraps the command and its flags is fine.

> you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability

I get the problems but I don't think I've ever had both at once. A need to portably wrap and share a specific command line for a specific program?

For the case of broadcast it seems easiest to just document the proper command line options. For the case of "unicast" I can just ask the other person what their environment is so I can craft the appropriate wrapper for them.

The area of overlap in the Venn diagram is infinitesimally narrow.