It turns out options parsing is fundamentally hard. It looks simple at first, but then it turns out that if you want to support everything anybody could possible want, you end up with some too complicated to use. Nor is it obvious which "middle ground" is correct. It's a perfect environment to produce exactly what we get, which is a bajillion options parsers for every halfway mature language in the world.
Also, that's not 400 lines of parsing code, that intermixes "parsing" and generation all together.
Mind you Go is not a good language for writing parsers in. (It isn't especially bad, like, say, C, but it lacks almost every conceivable feature that could make parsing code anything other than very, very verbose.)
Just to expand on this: options can be position-dependent, and treat options as an algebra (a --and b --or c); or, just executed in order to eg change directory (-d dir1 a b c -d dir2 x y z).
Basically, by treating the arguments as a stream of tokens, it can be parsed with the same power used for parsing the source of programming language.
Yet for many uses there are natural complexity-levels for option parser tools (like position-independent boolean options, and options taking one argument), hence the many tools for many niches.
And they are easy to write, so everyone writes one.
Also, that's not 400 lines of parsing code, that intermixes "parsing" and generation all together.
Mind you Go is not a good language for writing parsers in. (It isn't especially bad, like, say, C, but it lacks almost every conceivable feature that could make parsing code anything other than very, very verbose.)