Updated dramatically after 69 upvotes, see answer history for original answer. Thanks to @JimmyJames for the discussion.
First, let's talk about threat model: what are you trying to stop the potential attacker from doing?
Threat model: identity theft / ransomeware on a single-user system
Generally for end-user systems the de facto threat model is identity theft / ransomware. If the attacker has access to your documents and/or can run shell commands as you, it's game over. From that perspective, root access doesn't gain the attacker anything; they can get what they want without it.
If identity theft / malware is the only thing you're worried about, then it doesn't seem like it matters much whether your user has
sudo powers, or ever whether the browser is running as root.
(I should also point out that malware / connecting you to a botnet can happen without root access since login scripts / scheduling a cron job does not require root).
Randall Munroe at XKCD seems to agree with this view:
Lastly, I'll add this disclaimer: Yes, I'm aware that this goes against the general public opinion that "more security is always better". It's just not true. Sometimes more security is worse, like overly complex password policies that end up forcing people to write down their passwords. You always have to look at the risks and decide how much security is actually appropriate. In this case there's no harm to locking down root access, but you are making your life more complicated and it's not clear that you're gaining anything from it.
Threat model: root access or multi-user system
If you have a threat model where the attacker wants something that only root has access to, or there is more than one user account on the machine, then the answer actually depends on which *nix you're talking about. This is quickly getting away from personal computer cases and into server cases, but I'll discuss anyway. For linux, because of a bug (*ahem feature*) in the Xorg windowing system, your everyday account should probably not have
sudo powers. For operating systems that don't use X, it's probably ok.
Linux (running X.org window system)
Here's a great article that shows you how to log all keystrokes on a gui linux machine using a simple user-land (non-root) shell command. In summary:
$ xinput list shows you all connected human-input devices
$ xinput test <id> starts echoing all keystrokes on the selected device.
I tested and I get logs of the password that I type into
sudo in a different terminal window. If I lock my computer then when I log back in, I see logs of the password I typed into the lock screen. Apparently this is not a bug in X, it's a feature. Right, I'm gonna go hide under my bed now.
So yeah, this supports the idea that any user you log into in the gui with should not have
sudo powers because it's trivial to log your password and then become root. I suppose you should have a dedicated account for
sudoing and switch to a TTY terminal (
ctrl+alt+#) when you want to use
sudo. Whether or not this is worth worrying about is up to you: personally, all the data I care about is already there in my user account, but I probably will change my laptop setup because I'm a security nerd.
Note that in my tests I was not able to keylog across users. Doing "Switch Account" in the gui, or
startx in a new tty terminal seems to launch an isolated instance of X.
Thanks to @MichaelKjörling for this observation:
That's one of the things that Wayland [windowing system designed to replace X] actually tries to fix (see the bullet point on security). Remember that X11 originated at a time when the threat model was hugely different from what it is today.
For sysadmins: this reinforces the habit of only interacting with your Linux boxes over ssh, never use the GUI.
I'm not an OSX expert, but I know that it does not use the Xorg server so I would assume that Apple's GUI handles this properly, but I would love for someone more expert than me to weigh in.
I'm not a Windows expert either, but I believe that the User Account Control (UAC) feature introduced in Windows 7 addressed this by having admin prompts render in a secure desktop whose input busses are isolated from your regular desktop.