Use gperf for command line parsing?

I'll agree with the authors of this article that command line processing is an oft neglected block of software implementation that ends up being thrown together and regretted forever. I don't think their article's solution is completely appropriate to the problem they present, and may be leading many programmers down the path of premature optimization.

In effect they say:

Problem:
1. command line parsers are often implemented as ugly if then else if unmaintainable code
2. typical command line parsers are O(n^2) performance

Part 1 can hardly be argued with. This is just bad (tm).
Part 2 is where I take umbrage. How many programs have so many command line arguments they need to worry about O(n^2) drag on command line parsing? Compilers. EDA tools. Can you think of any others?

Now these guys are EDA tool builders, and if they'd come out and limited their scope by saying this is appropriate for some limited segment of software I'd be happy as a clam with the article. However, by including part 1 of their problem description, they imply that all software should use gperf for command line parsing.

I'd say: all software should use command line parsing library functions such as GNUgetopt(). If after everything is working and you notice performance is being dragged down, then you ought to look into new tools such as gperf.

Use gperf for efficient C/C command line processing