[ymherklotz]

The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs. I can use all of my usual navigation keys to move around the documentation of the variable, evaluate things inline, etc.. Just as if it were more text, which is what Emacs is already great at. I would mind the buttons getting a more modern look, but I think everything being text what makes it works this seemlessly, and it would be much tougher to get a uniform feel with graphical windows.

[alwaysbeconsing]

There's no reason keyboard navigation can't work in a GUI context. In fact it might be easier to define things like "up" or "forward" since widgets will often have a natural hierarchy with direct references to each other, so there's no need to parse anything to figure out what the "sexp" is.

[ParetoOptimal]

One problem is that macros currently work even in things like the settings buffer. If you change that to GUI, depending on the implementation, I'm not sure if that stays true.

For a settings buffer, maybe it doesn't matter. However macros working everywhere in your editor as a default is quite powerful.

[alwaysbeconsing]

I don't follow. Macros are literally just vectors of input events; if keyboard navigation works, then so will a macro that replays that navigation. (It is also already possible to record a macro that includes mouse events.)

[ParetoOptimal]

> The benefit is uniformity, everythings the same, which is one of the main reasons I use Emacs

Not only the uniformity in use, but also the uniformity in how you extend would be lost.