> > Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.

That analogy makes one significant assumption: that you are trying to order food from McDonalds, which is a thing you are used to doing at place you are already familiar with. Of course it's more difficult to learn Korean when you just want to order some American food, but what happens when you try to order Korean food? What if you are trying to do something more complicated than order food? There are cases where learning Korean would be clearly beneficial.

The limitations of GUIs stand out most in technical tools. When the thing a user is trying to do is already complicated, it doesn't really help to give them a simplified menu system: that just provides a frustrating amount of options.

There has been a significant prejudice in UI/UX design to optimize for approachability, even when expressiveness is a better target.

Ordering food is a great use case for "point and nod" UX. The pointing and nodding only needs to occur a small number of times. There is much more need for approachability than expressiveness. To contrast, editing text is a terrible use case. A point and nod system would involve a fatiguing amount of pointing and nodding. There are reasons that tools like Vim and Emacs are widely popular, even with their steep learning curves.