Whether the "help" feature is resonable at all, may be discussed. But if yes, it is better in my opion to use the built-in variant, simply because it is always in sync with the actual configuration. An external module would have to be re-tailored constantly.
And yes, keeping the size in focus is mandatory. But memory sizes of devices increase, and for instance the 512k target of ESP8266 seems not really of interest any more, whereas last year it still seemd to be a valid objective.

On baremetal help('modules') lists frozen bytecode. As far as I know this has to be in C because FBC exists outside the filesystem. If on Unix everything is in the filesystem, modules in the Python path can be located and listed in Python. No syncing required. Or am I missing something?

Even if it is undesirable to have this enabled by default, doesn't it at least make sense to include the related configuration options in the "mpconfigport.h" file so that others have a chance to figure out how to enable this without having to investigate how it works for other ports?

1. We have all configuration options listed in py/mpconfig.h.
2. For different uPy users, different options are interesting and important. For example, you say it's *_HELP, someone else may want something else, to satisfy everyone, we'll need to duplicate py/mpconfig.h content.
3. @dpgeorge specifically said he doesn't want options with default values to be set in mpconfigport.h (i.e. there should be only overrides. (I'd personally be happy to make exception for some options, including ack'ing yours proposal for *_HELP).

But memory sizes of devices increase, and for instance the 512k target of ESP8266 seems not really of interest any more, whereas last year it still seemd to be a valid objective.

Memory size of my devices doesn't increase - the boards I have in my drawer for 3 years has the same amount of memory as before, ditto for various routers, etc. ;-).

In general, the outlook of this problem is described in https://github.com/micropython/micropython/wiki/ContributorGuidelines : there're two alternatives: CPython, which has builtin help on Unix, with which we don't want to compete, and other small languages, with which we want to stay competitive. Otherwise, uPy is very configurable and everyone should be able to adjust it for their needs, the default config however emphasize uPy's strong sides, which are: small size, and competitiveness with other small-size languages.

On baremetal help('modules') lists frozen bytecode. As far as I know this has to be in C because FBC exists outside the filesystem. If on Unix everything is in the filesystem, modules in the Python path can be located and listed in Python. No syncing required. Or am I missing something?

Help can be implemented as:

def my_help(*args, **kwargs):
    # Do what you want

import builtins
builtins.help = my_help

That can be imported from site.py or boot.py (we didn't decide which unix port should use, thus not implemented). If some things aren't doable, they can be implemented (optional; default off; with tests to not decrease coverage).

Why don't all the ports use a Python implementation if that is preferred?

Because all ports have different requirements and usecases.

We have all configuration options listed in py/mpconfig.h.

Thanks for mentioning this. I had not encountered the py/mpconfig.h file yet. Maybe I'm not appreciating its intent, but it does seem like something that isn't a great idea to modify locally.

it can be implemented in Python

How would one go about enumerating the available modules from Python that are not on the file system? This would include the stuff that comes standard with MicroPython and additional frozen code. I spent 20 minutes trying to figure this out, and was unsuccessful. I also looked at how the C implementation works, but I don't see where any of the C plumbing that it is being used is exposed to Python.

This was enabled in 6430cd3 (on standard and dev variants of the unix port).