À l'origine, sudo c'est un outil pour gérer granulairement l'accès à certaines commandes à une époque où le bureau était inexistant. Aujourd'hui, on utilise sudo à tort et à travers sans aucun avantages par rapport au mécanisme super-utilisateur classique.
Premièrement, tu as le problème du timeout avec sudo (15m sous Ubuntu par défaut), deuxièment, avec sudo tu octroies potentiellement des privilèges à des millions de lignes de codes non audités (Xorg, Gtk+, etc ...).
En lieu et place de sudo, Fedora utilise PAM/ConsoleHelper qui est un moindre mal, mais qui est progressivement remplacé par PolicyKit, plus adapté au paradigme bureau.
Pour résumer, PolicyKit permet une gestion fine des droits selon un principe client/service (pas d'erreur, c'est un service dbus). Ton client demande le droit d'exécuter une seule action, PolicyKit vérifie qu'il a le droit d'effectuer cette opération et transmet ou non la requête à un service. Seul le service en question a les priviléges, pas les clients, donc moins de code tournant sous des priviléges élevés, une authentification plus fine (PolicyKit peut distinguer un utilisateur local, d'un utilisateur distant), etc ...
Le seul inconvénient de PolicyKit, c'est la nécessité d'intégrer le framework à l'application.
Pour en revenir à PackageKit, PackageKit s'appuie sur PolicyKit, d'où le fait que l'installation de paquets en non-root ne marche pas pour un utilisateur distant, que ça n'affecte que le mécanisme d'installation de paquets (on peut difficilement détourner PackageKit pour une élevation de droits), et ça ne marche que pour les paquets signés (par défaut, les dépôts officiels)
Certes, c'est moins sécurisé que le comportement précédent puisque l'administrateur ne peut pas filtrer les paquets installés (enfin, quand on administre un parc, on personnalise un minimum les installations) mais ça reste un zillion de fois mieux que sudo/gksudo. Enfin, ça change pas grand chose pour les utilisateurs desktop.
Le seul truc à craindre, c'est qu'un paquet contienne une faille mais c'est valable pour tout le monde. Mais dans ce cas, c'est oublier la politique de sécurité proactive (sécurité préventive) de Fedora (on est la seule distribution "grand public" à le faire) c-a-d SELinux et ses amis qui permettent de confiner la plupart des failles par avance. Pour plus de détails sur la sécurité d'une installation Fedora, je vous renvoie à l'excellent security guide (également disponible via yum)
http://docs.fedoraproject.org/security-guide/f12/en-US/html/