Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect.
Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard that the recent generation of Windows is more terminal-friendly). In particular, Linux convention does a better job of sandboxing apps into users, while in Windows anything important runs as System, while the Linux GUI (X Server) sucks at security, and the Windows GUI has fancy things like UAC built-in. Basically, Linux is (and always has been) a server first and a workstation second, while Windows is the other way around.
Security Models
As far as "the OS" (ie the kernel) is concerned, you have 7 tty consoles and any number of SSH connections (aka "login sessions") - it just so happens that ubuntu ships with scripts to auto-start the GUI on the tty7 session, but to the kernel it's just another application.
Login sessions and user accounts are sandboxed quite nicely from each other, but Linux takes a security mindset that you don't need to protect a user from them-self. In this security model, if your account gets compromised by malware then it's a lost cause, but we still want to isolate it from other accounts to protect the system as a whole.
For example, Linux apps tend to create a low-privilege user like apache or ftp that they run as when not needing to do rooty things. If an attacker manages to take control of a running apache process, it can muck up other apache processes, but will have troubles jumping to ftp processes.
Note that Windows takes a fundamentally different approach here, largely through the convention that all important things run as System all the time. A malicious service in Linux has less scope to do bad things than a malicious process running as System, so Windows needs to go to extra efforts to protect someone with admin rights from "them-self".
GUI environments and an X Server that was not designed for security throw a wrench into this security model.
Gnome gksudo vs Windows UAC, and keyloggers
In Windows, when a user-process requests privilege escalation, the kernel throws up a special protected prompt whose memory and keyboard / mouse bus is isolated from the rest of the rest of the desktop environment. It can do this because the GUI is built-in to the OS. In Linux, the GUI (X server) is just another application, and therefore the password prompts belong to the process that invoked them, running as you, sharing memory permissions and an input bus with every other window and process running as you.
The root prompt can't do the fancy UAC things Iike lock the keyboard because those either need to be root already, or require totally re-designing the X server (see Wayland below). A catch-22 that in this case is a downside of separating the GUI from the kernel. But at least it's in keeping with the Linux security model.
If we were to revise the security model to clamp down on this by adding sandboxing between password prompts and other processes running as the user in the same GUI session, we could have to re-write a great many things. At the least, the kernel would need to become GUI aware such that it is capable of creating prompts (not true today). The other go-to example is that all processes in a GUI session share a keyboard bus.
Watch me write a keylogger and then press some keys in a different window:
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
Any process running as you can sniff the password in another process's prompt or terminal and then call sudo on itself (this follows directly from the "no need to protect you from you" mindset), so increasing the security of the password prompts is useless unless we fundamentally change the security model and do a massive re-write of all sorts of things.
(it's worth noting that Gnome appears to at least sandbox the keyboard bus on the lock screen and new sessions through "Switch Users" as things typed there do not show up in my session's keyboard bus)
Wayland
Wayland is a new protocol that aims to replace X11. It locks down client applications so that they cannot steal information or affect anything outside of their window. The only way the clients can communicate with each other outside of exterior IPC is by going through the compositor which controls all of them. This doesn't fix the underlying problem however, and simply shifts the need for trust to the compositor.
Virtualization and Containers
If you work with cloud technologies, you're probably jumping up and down saying "Docker is the answer!!". Indeed, brownie points for you. While Docker itself is not really intended to enhance security (thanks @SvenSlootweg), it does point to using containerization and / or virtualization as a forward that's compatible with the current Linux architecture.
Two notable linux distributions that are built with inter-process isolation in mind:
Qubes OS that runs user-level apps inside multiple VMs separated into "security domains" such as work, banking, web browsing.
Android that installs and runs each app as a separate low-privilege user, thus gaining process-level isolation and file-system isolation (each app is confined to its own home directory) between apps.
Bottom Line: From the perspective of an end-user, it's not unreasonable to expect Linux to behave the same way as Windows, but this is one of those cases where you need to understand a bit about how the underlying system works and why it was designed that way. Simply changing the implementation of the password prompts will not accomplish anything so long as it is owned by a process owned by you. For Linux to get the same security behaviours as Windows in the context of a single-user GUI workstation would require significant re-design of the OS, so it's unlikely to happen, but things like Docker may provide a way forward in a more Linux-native way.
In this case, the important difference is that Linux is designed at the low level to be a multi-user server and they make the decision not to protect a user from them-self, while Windows is designed to be a single-user workstation, so you do need to have inter-process protections within a login session. It's also relevant that in Windows the GUI is part of the OS, while in Linux the GUI is just another user-level application.
