The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the 1990s, students did not usually have networked computers, in particular laptops; more commonly, the students were sharing a dozen workstations in a dedicated room. The students, being students, engaged into the kind of things that students do, in particular setting traps and jokes on each other. "Stealing" the password of a co-student was a common game.
And game here is an important word. The point was not really to have the password to enact mischief, but to demonstrate technical skill for boasting purposes (most human activities, at least from male people, are at their core about gaining or keeping Alpha male status, even to the point of absurdity because computer rooms of the 1990s were singularly devoid of any female that could have been wooed by such a display of technical skill). Thus, the "password stealing" needed not be efficient but elegant. This included amusing systems by which a user would keep a picture of the login screen running as a basic application under his own name, mimicking the true one and grabbing the password of other people -- the elegance coming from the fact that the attacker does not even need local administrative rights ("root privileges"). You will notice that the SAK prevents exactly that attack.
Real-life attackers don't play that nicely. When they have physical access to a machine, they first get kernel-level access, possibly by physically damaging the machine (an unthinkable heresy for a computer student), and if they want to log keys they just do, regardless of the SAK. But engineers who design operating systems now still think in terms of the golden days of their early twenties; they try to thwart not the practical real-life attacks, but the elegant shenanigans from a more civilized age.
So the SAK is there, mostly to give a feeling of safety to people who envision attacks and key logging like a game they played two decades ago and still fondly remember. Like most things in computers, it is there out of a matter of Tradition.
(Note that some of these engineers did not get jobs designing operating systems, but writing specifications of "security rules" to which organizations shall conform -- for an hilariously extended effect of lingering tradition. OS designers still have to include a SAK because they need it to comply to some regulations, even if they know it does not make a lot of sense.)
Now, in practice, what good does the SAK make ? Not a lot. One can still say that the login password of a user is sensitive data -- not because it grants access to the local network (an access that the attacker already has, by virtue of hijacking a machine that runs on that network), but because users have the habit of reusing passwords, either directly or through some transparent "rule" (if user's password on server QZ982 is "PasswordQZ982", guess what will be the user's password on server YH455 ?). But the SAK is not enough to resist key logging anyway.
Security is really increased, not by SAK-like attempts, but by (as usual) educating users, in particular to the necessity of not reusing passwords.