Do sudo and .profile/.bashrc enable trivial privilege escalation?

Anything you can do on a compromised account, an attacker can do as well.

Fundamentally, this is because Linux providers isolation between users, not between individual processes running as the same user. Any process running as a given user is considered to have equivalent capabilities as any other processes running under that user.

Is it true that the system sudo executable can be circumvented in this way?

Yes, and in other ways as well. If you elevate privileges to root on a compromised unprivileged account, you compromise root. If you drop privileges from root using su to an unprivileged account, you also compromise root! You can never safely elevate privileges on an untrusted account. While it's possible to exploit the system using PATH, it's also possible to hijack the bash process itself to sniff key input. Disabling execution with noexec is further not useful because interpreters (bash, python, perl, etc) will still run. The noexec option is not and has never been designed as a security feature, despite it being regularly peddled as such.

An incomplete list of ways an attacker could hijack the use of sudo or su:

• Using the LD_PRELOAD variable on the parent process (e.g. bash).

• Hooking the parent process with ptrace() or process_vm_writev().

• Sniffing or injecting keystrokes into the terminal emulator using the X11 protocol.

• Creating aliases or functions to wrap the actual sudo executable.

I explained these in more detail on my answer to another question.

Why are desktop Linux systems, by default, set up in such an easily exploitable way?

Elevating privileges on an untrusted account is not something you are supposed to do. Not to mention, desktop Linux is an afterthought in the grand scheme of the general *nix architecture. It is a failure of security theater incessantly repeating the same bad advice, not a failure of the security architecture of Linux itself. People repeatedly say to use sudo for root because many new users will instead run everything as root, even their browsers! In this case, it is better to be using sudo. It is harmful in the case where the user is already smart enough not to use root for everything.

Note that sudo is highly configurable and can be designed to allow only certain commands. This is where it really shines. You can configure sudo to only allow you to run apt-get update as root (with or without a password), and deny everything else. That would additionally restrict an attacker from doing anything other than... well... doing a software update.

It's important to remember that, even if you configure it to only allow running certain commands as root, you can still shoot yourself in the foot if you whitelist programs that are not designed to run as root via an untrusted user. I saw a real-life example of someone trying to run VeraCrypt in this way and explained why it is insecure. The idea was that VeraCrypt is safe to run as root, so it should be safe to use sudo to elevate it to root as an untrusted, unprivileged user. It turns out the idea is flawed, and allows trivial privilege escalation!

Shouldn’t the default way to invoke sudo make sure that it is, in fact, the executable provided by the system (nobody is going to type /usr/bin/sudo every time)?

Typing the full path will not protect you! You can easily create a function that contains a leading /, and it will override the real executable. Even if the executable did make sure that it is genuine and attempted to defeat sniffing, a malicious process could hijack the bash process and sniff keystrokes independently of sudo, making it impossible to detect from its point of view.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

In such an environment, it seems that using sudo is fundamentally insecure and one would be better off enabling login as root and logging in on a separate TTY.

This is always the case. Note that even logging into another TTY is not perfectly safe. You should use SAK, the Secure Attention Key combination, to ensure that you are interacting with a genuine login session (agetty or logind, for example). SAK is a key combination that the kernel listens for (and thus cannot be repressed by userspace). When it detects it, it will kill every process in the current TTY, triggering the login prompt to appear. If you have switched to a genuine, uncompromised TTY, then it will only cause the prompt to disappear and reappear. If you are on a hijacked TTY, it will kill the malicious process and bring back the genuine login prompt.