~50% of the modules here are not-strictly about CLI-generation, but other functionality I have found useful in several-to-many CLI utilities. Being here means a "script writer" who wants a nice CLI and various support not in Nim's stdlib need only git clone https://github.com/c-blake/cligen there (which they already know) and nim --path=there myThing. They needn't read tutorials, about 6 alternative package managers or build systems, about dot.nimble files or versioning rules - nada. Trying out a new prog.lang. with an easy CLI framework and niceties is classic, though. So, I feel secure in the idea that cligen itself should remain dependency-free.
Such users may not investigate the support modules, of course, and it may be an overachieving level of extra support (the kernel module in particular). OTOH, the "more I want to tweak --help output the more I must learn" is already a part of the "workflow" of becoming a cligen-power user. Also, it also keeps the dep tree of my other packages very shallow -- alleviating package manager hassles for them as well.
Anyway, these files are not many bytes. There could be "dark" (unpublished) code anywhere that imports them. The nature of cligen and PL experimenting, as just described, makes such dark code more likely here than for other packages. So, at a minimum a long deprecation period before removal is warranted. This discussion has more details if you want to chime in.