When you type something like:

find-junk | xargs rm -f
[download]

... and find-junk bails out with an error message, you don't want the error message piped to rm -f, do you?

So a convention has arisen to provide usage instructions on STDERR if the program has been called incorrectly, but on STDOUT if the program has been called with an explicit --help.

fisher's suggested code does precisely this. It only selects STDERR if $err is a true value.

When you type something like

That is a very specific case , I never do stuff like that (xargs + rm )

Error messages should go to STDERR, Log to the log or STDERR if no log wanted/specified, and required/expected output to STDOUT.

If you read that again, an expected usage message is something you want on STDOUT. e.g. when called with --help. My approach is always:

sub usage
{
    my $err = shift and select STDERR;
    print "usage: $0 [--options] ...\n";
    exit $err;
    } # usage

use Getopt::Long qw(:config bundling);
my $opt_v = 0;
GetOptions (
    "help|?"      => sub { usage (0); } # OK, STDOUT
    "v|verbose:1" => \$opt_v,
    "x|xfsgdft!"  => \my $opt_x,
    ) or usage (1); # FAIL: STDERR
[download]

As not all programmers are clean in that distinction, when I want help through a pager, I pipe STDOUT and STDERR together, which - in (t)csh is just a single extra character:

> some_app --help |& less
[download]

To return to the first point, when some script/app deals with lot of data, you absolutely want that separated! You want to see the analysis, and not store it between your data

$ perl foo.pl big_file.txt >excerpt.csv
Opening file …
Analyzing columns …
Validating data …
Generating CSV … 1 2 3 4 5
Done!
$
[download]

Imagine the validity of the generated file if the diagnostics were sent to STDOUT. And imagine the extra time it takes to wade through all the lines to find those messages.