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.