Mmm I would argue that using -o may make failures non-destructive at the discretion of the author of the program. I don’t know what the program does. Does it safely and securely create a temporary file, then write the contents to it, then rename the file? This would need to happen on the same file system as the target file for the rename to be atomic and there are few guarantees that my current user has the permissions to write to any file other than this one. It also would certainly fail if the file system is full.

Or the program could start out by deleting my file and starting to line buffer write to it as it executes. Then the failure would be the same as shell redirection. Or it could buffer differently making program failure even more fun.

My point is that I don’t know what the program will do, or even what this particular version will do, without looking at its code.

Shell redirection has predictable semantics. And I can output to a different file, run diff on the two, then rename myself, if this is truly critical. And muscle memory will be faster than looking up the specific option or argument for this specific program.

It does when one is a standard convention compatible with all programs whereas -o does different things for different programs. For example, grep -o foo will print only the parts of the input stream that match "foo" but grep > foo will write to the file foo. Some commands don't even have a -o flag like "cat" but output redirection is still always an option.