It's certainly the case that *gnome* might do something
you 'sudo gedit' something, but 'sudo emacs' really ought to be
equally acceptable regardless of whether you're using the terminal or
emacs is probably okay, just by virtue of the fact that if the admin
the user the right to run emacs as root, they almost definitely trust the
user with general root access.
In that same light, it's probably fine if the user running sudo has full
access to sudo anyway, but it's considerable riskier if it's a restricted
sudo configuration or say consolehelper (or worse a setuid application!).
The problem is that X is a big api and it's designed with the notion that
everyone who has access to the display is pretty much at the same
trust level. It's possible to prod and poke at one client from other clients
in pretty arbitrary ways.
As I know you know, it's generally a good idea to have code running
with elevated privileges as self contained as possible and accessible
with as narrow an interface as possible.
the wayland protocol is a little better than X, it doesn't let clients see
much past themselves, or let them influence other clients in as ad hoc
of ways. Still, code running with elevated privileges should be *small*,
doing whatever job it's supposed to do. And that job shouldn't be
interacting with the user. you don't need elevated privileges to interact
with the user, so why would put the code to interact with a user in a
process running with elevated privileges ?
polkit solves the problem nicely because it encourage separating
mechanism from interface, and gives fine grained control via named
actions, not programs.
Anyway, that's the argument, as I understand it, in broad strokes.