Traditionally applications will print usage (which is usually the same as --help) if arguments are missing or invalid flags are given. This is clearly an error condition, and it would be very bad to print the output to stdout in that case. --help will simply call usage(), so there's no difference in behavior. I think it would be feature bloat / overkill to have programs print usage to stdout or stderr depending on how it's invoked, even if it's easy to implement.
Even so, is it really advantageous to have "foo --help" send usage info to stdout, but for "foo -?" to send "Invalid switch '-?'" followed by usage info to stderr?
More importantly, usage information doesn't conform to the structure of ordinary program output, and can therefore be annoying or even dangerous if inadvertently treated as such, so it really, really does belong on stderr for any program whose stdout might reasonably be used as input to another program.
That's a weird, conceptual argument (and program output is not strongly typed). I just want "program --help | less" to work, especially when there's a lot of options.
> usage information doesn't conform to the structure of ordinary program output
This is weak. Pretty much every command line program will have multiple flags that change the output in some profound way. Why should --help get special treatment?
Most people think stderr (so as not to muck up pipelines when you get the invocation syntax wrong). But then there is also the cleverer option of using stdout if and only if the help is explicitly requested, which seems to be justifiable, popular in the survey, but (I think) not much implemented.
$ openssl enc --help 2>&1 | grep gcm -aes-128-ecb -aes-128-gcm -aes-128-ofb -aes-192-ecb -aes-192-gcm -aes-192-ofb -aes-256-ecb -aes-256-gcm -aes-256-ofb
(Tested on ArchLinux with OpenSSL 1.0.1.e-5)