I imagine it was originally written that way to be consistent with the help message generated when, for example, no arguments are given:

raku -e 'sub MAIN($foo) { }' --help
Usage:
  -e '...' <foo>

raku -e 'sub MAIN($foo) { }' > /dev/null
Usage:
  -e '...' <foo>

Could be but at the end of the day, if you pass only --help to a CLI that wants arguments, it will also write to stdout. So right now it seems that multi just overrides the default behavior to the opposite and I can't see the benefit of this.

There are other considerations as well. For instance https://github.com/Raku/Blin/blob/253df4c042a1fb8cd0fd92ccedf9ce3fb9bcca70/lib/Blin/Tester/Zef.rakumod#L26-L27 (and other code like this) should be updated to use run(..., :merge).out instead of run(..., :err).err for the immediate future

Yes, "immediate future" because I think depending solely on stderr was a mistake whether the test passed or not.

I can try to hunt these locations down in the code if that moves the case of the zef help forward.

Yes, that would expedite the process. Another instance is https://github.com/lizmat/Zef-Configuration/blob/11a474467f9f8eed8a00108adbe843e73090b2c9/lib/Zef/Configuration.rakumod#L415-L416

There used to be a bot/tool in IRC that could grep the ecosystem that would probably prove useful

Yes, the bot still exists https://gist.github.com/Whateverable/f3c945c5c02a7acb811e68163e9855bf but I'd assume it can only check p6c content. If it could be adopted to use REA, then it would be quite useful again...

That query isn't really sufficient. Something like zef.*?--help would be better.

The difference is not big at least: https://gist.github.com/Whateverable/7016caa7a3edaa7ce6e692ffa7df4bd7

To be honest, what really should lead to some questions is the fact that anyone decides to depend upon the content (let alone the handle) of the help output of any tool really...