... or, oops, I put my basket of eggs outside this airtight hatchway.
When I say privilege escalation vulnerability, I'm talking in the context of operating system user accounts - going from executing code as a normal user, to a root or administrator level without proper authorisation. I'll discuss this in two separate contexts: desktop PCs, and servers.
What really matters on your personal machine? Your personal information. Login credentials. Emails. Private messages. Cookies. API tokens. Banking information. Browsing history. Photos.
If an attacker is able to get code running on your machine as your normal user, they have access to all of that. They can read all your files. They can log your keystrokes. They can even read the memory straight out of your running processes. Everything you actually care about is running in your normal user account - so if an attacker, for example, tricks you into running a malicious exe file, or exploits a PDF parsing bug in your mail client to gain RCE, they will already have access to everything useful.
There is no need for them to use a privilege escalation exploit, because what does it get them? They can bind port 80? Delete System32? Who cares, they have your passport scans and recent utility bills. And they're going to send your grandmother webcam captures of you masturbating unless you wire $20k in bitcoin to 0xDEADBEEF in the next 20 minutes.
Let's imagine you're running a web service of some kind, on a VPS or cloud instance. You have a special user for your backend, which runs with minimal privileges. Let's also imagine that your web service has an exploit in it which allows an attacker to gain RCE. Great, now they can run custom malicious code as your service user, but it's ok because they don't have root, right? Wrong. Your service user is running code that connects to an SQL database which contains all your customer info. So by definition, the required credentials to connect to that database are available somewhere accessible to that user. All they need to do is find it, and next thing you're on the front page of HIBP.
There's no need for them to bother getting root on your server, because your server probably does only one thing, and the user they initially got access to is probably the user that does that one thing.
What about multi-user desktops? What about machines that run several different services with isolated user accounts? What about forgotten and vulnerable OS components that listen on a network socket? What about my one special system where all the juicy stuff is in ~root and not connected to a network service?
I'm not denying that situations exist where privilege escalations can matter. What I'm arguing is that for the overwhelming majority of cases, it really doesn't. How many multi user desktops have you used in the past year? And of them, how many actually used different accounts for each user, vs a single user called "User"? What proportion of servers running CRUD app web services do you really think have anything else of interest going on under a different user account? Don't VMs / containers provide better isolation than user accounts anyway? The utility of worrying about this issue is minimal, so maybe we should just stop. Personally, I did long ago.
As a parting thought - consider what a modern OS kernel which didn't care about preventing privilege escalation might look like. Where might we spend all that freed up dev time? Would we gain performance by omitting complex permission checks? And would we avoid real vulnerabilities by having an overall less complex codebase?