Why should one use sudo?
Because sudo allows much finer-grained controls than "login as root then do whatever you want." For example you can configure sudo so that some users are only allowed to run certain commands (like wrapper scripts or "acceptable" binaries). You're concerned about a trojan horse compromising a single-user's computer, but sudo was created to allow logging and access control on a server that is administered by multiple people.
Of course on a single-user system, the important files are the user's files, and once you get access to the user's account you already have access to those files, so getting the password is not even that important anymore. Even if the password is your goal (say, you're attacking someone who reuses passwords) there are plenty of ways to get it without involving sudo; for example, I've recently encountered 2 installed-by-default programs that will log passwords or password errors in plaintext.
And finally, it's advisable to not run as root whenever possible because the consequences of mistyping a command (rm_-rf_._/ is an obvious example) aren't as severe. Requiring the extra step of writing sudo at the beginning of a command as opposed to "forgetting you're logged in as root and doing something destructive" can avoid some simple but serious mistakes.
There are valid convenience uses for sudo, but because they are already adequately explained in other posts, I won't elaborate on them much here. I will however point you to sudoers(5), which is the sudo configuration file. It shows some of the extensive configuration possible with sudo. I will be explaining when and why you should not use sudo to elevate from your normal user to root for purely security reasons, convenience aside.
Short answer: There is no way to securely use sudo if your regular user may be compromised. Use it only for convenience, not for security. The same applies to su and all other programs that may be used to elevate your regular user to a more privileged one.
Long answer: It is not true that using the full path for sudo will protect you from a malicious environment. That is a common misunderstanding. A bash function can even hijack names that contain a / at the beginning. Try running the following:
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
You must only use option 1, aka logging in with agetty or logind on a different tty (note that on some distros, tty1 is where Xorg is running, such as Fedora. On most distros however, tty1 is a spare tty and Xorg runs on tty7). However, you must be aware that malware can hijack ctrl+alt+f1 and present you with a fake screen, so you must use the Secure Attention Key combination (SAK, which is alt+sysrq+k on Linux systems), which kills all processes in that tty. This kills any fake login screen and brings you to the real one only. If there are no fake login screens trying to steal your root password (which is hopefully the case), then it simply causes agetty to restart, which should appear as nothing more than the login prompt blinking. On some systems, many SysRq features are disabled, including SAK. You can temporarily enable them all by writing the integer 1 to /proc/sys/kernel/sysrq. The value of /proc/sys/kernel/sysrq is a bitmap, so look into what it currently is and calculate what you need to convert it into to add SAK support before making it permanent in /etc/sysctl.conf. Setting it to 1 forever can be a bad idea (you don't want just anyone to be able to alt+sysrq+e to kill xscreensaver, do you?).
The idea that you can protect your regular user and use sudo or su safely is a very dangerous idea. Even if it were possible, there are countless ways to hijack your running session, such as LD_PRELOAD, which is an environmental variable that points to a shared object (library) which will be forcibly loaded by the program to change its behavior. While it doesn't work on setuid programs like su and sudo, it does work on bash and all other shells, which execute su and sudo, and are the ones who see all your keystrokes. LD_PRELOAD isn't the only variable which can hijack programs running as your user. LD_LIBRARY_PATH can tell a program to use malicious libraries instead of your system libraries. There are many more environmental variables that can be used to change the behavior of running programs in various ways. Basically, if your environmental variables can be compromised, your user, and all keystrokes entered as that user, can be compromised.
If that weren't enough, on most distros, your user can use ptrace() with the GETREGS or PEEKTEXT/PEEKDATA options to view all the memory of processes running as the same user (such as the bash process which is running su or sudo for you). If you are using a distro which disables that (e.g. by using the Yama LSM), the process still may be able to read and write to your bash process' memory using process_vm_readv() and process_vm_writev() respectively. On some kernels, you can also write directly to memory through /proc/pid/mem, as long as the process writing to it is the same user. In the Linux kernel, there are countless security checks all over to make sure processes cannot interfere with each other. However, they all involve inter-user protection, not intra-user protection. The Linux kernel assumes that every single thing done as user A is trusted by user A, so if you su to root as user A, then root must be just as trusted as that user.
Before I even get on to Xorg, let me just start out by saying Xorg provides no protection from keyloggers. This means that, if you use sudo or su in a tty with Xorg running, all processes running as that same user will be able to sniff (and inject) keystrokes. This is because the X11 protocol's security model assumes that anything with access to the X11 cookie is trusted, and that cookie is accessible to everything running under your user. It is a fundamental limitation of the X11 protocol, ingrained as deeply as the concept of UIDs are on Linux. There is no setting or feature to disable this. This means that anything you type in an Xorg session, including typed into su or sudo (or frontends like gksu, gksudo, kdesu, kdesudo, pinentry, etc) can be sniffed by anything running as the same user, so your browser, your games, your video player, and of course everything forked by your .bashrc. You can test this yourself by running the following in one terminal, and then moving to another terminal and running a command with sudo.
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Note that if this specific test does not work for you, it means you do not have the XTEST extension active. Even without it active, it is still possible to record keyboard events using XQueryKeymap(). The lesson you should take way is that there is effectively no way to securely enter your password using su or sudo through a compromised user. You absolutely must switch to a new tty and use SAK, then log in directly as root.
Aside what's mentioned by the other users, sudo also keeps the original identity of the user that's executing the command. Meaning that you can track what userid performed the command. If you are using root in a multiuser environment, you will not be able to track the execution of a command to a single user as the uid will be 0.