The proper way to handle issues like these is process level permissions (i.e. capability systems), instead of user level. Linux CGroups, namespaces, etc. are already moving that way, and in effect that's the way windows is trying to head too. (Windows has its own form of containerization called AppContainers, which UWP apps use. Windows also has its own capability system).

The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it's UID can, which isn't great. And even still to this day that's how users execute a lot of processes.

Windows isn't much better here, though.

It's not about someone, it's about something. A lot of us aren't (only) using Linux as a server OS, but for desktop too, and desktop usage involves running much more different kinds of software that you simply just can't afford to audit, and at times there are programs that you can't choose to not use, because it's not on you but on someone on whom you depend.

Then it's not even only that. It's not only random shit or a game you got that can edit your bashrc and such, but if let's say there's a critical vulnerability in a complex software you use, like a web browser, an attacker could make use of that to take over your account with the use of a bashrc alias.

Nearly all tools (with flatpak and portals progressing into better directions but probably never finished) have rw permissions everwhere.

The modern OS threat model is not other users, as private users mostly have single user systems. It is malware and software doing nasty things.

On Linux this always worked out somehow, but grabbing your sudo password is not hard, just alias sudo to a script reading your argument, reading your password, and piping the password to the real sudo. You dont even notice it but that script just got your sudo password.

Dont know what Reddit has to do with that