Oh, do Windows firewalls do that? Anyway, yes, you could warn over any packages with SUID/SGID files. A user wants to install an app; a box pops up asking them allow or deny; how do they know that games do not need SUID root, and bail? They (mostly) don't understand that; they do understand that if they click deny, they can't have their game. You wanna bet that they click deny?No typo; those are categories of possible answers to that semi-rhetorical question. (Semi- because if you have other options, I am interested to hear them; I'm no expert on Windows firewall.)
My argument is that since they have precisely the same capabilities, they have precisely the same degree of protection; WRT installation of malware by the sysadmin, that would be "none".
How does software tell the difference? When you grant administrative privileges to any moderately sensible user, you grant them to everyone. Single-user machines run by people who don't know better can will get pwnz0red, and there's nothing you can do to stop that.
Any clue how many people are running KDE, xrandr, and other cool things? Just guess how many downloads a purported "App Mugger Fix" would get now! Lots of people would indeed download, trust, and run all sorts of things that did need full access, from all kinds of sources. And they'd be safe enough of the time that it would seem safe, until some malware did show up, because there are lots of system enhancements that can be made that would require it.

If they have the option, they will use it. And if they're used to using it ever, they won't even hesitate when some app they want claims to need to "update system libraries", no matter how obvious (to the knowledgable) that it should not.

Strawmen are triply wrong.

I didn't say new OSes, did I? I did mention the kernel rather than libraries, because it's possible to (at some cost) pack any library dependencies of an app into either an all-in-one sandbox, or an app-specific sandbox. (Major subversions are possible if I can replace shared libraries used by other apps with a modified version, but the latter means you might as well have everything statically linked.) But updating the kernel is not limited to "installing OSes". Xrandr, SDHC support on 770s, high-speed MMC, backlight control, DVB, various USB-OTG related modules... Lots of stuff here that requires root access.
Precisely; it's not a comment on sandboxes (which are a good idea, used in their place), it's an alternative explanation of why the NITs are not secure (vs. because we don't sandbox our apps, or as you originally suggested, because Linux firewalls are "potentially ineffective, as opposed to Windows ones").

Unless you suggest some sort of signing system or other lockdown for anything outside the sandbox (in which case Nokia can forget working with the F/OSS community to work through to step 5, as per their indicated plan), you still have that problem. Because it's "irrelevant to how a sandbox model works", a sandbox model can't fix it.

The current security model is the same as any UNIX box, which somehow get used anyway. The only difference is the application manager's automatic grant of root access; it's trivial to lock users out of (or remove) App Mugger, and require IT authentication to update software. It's an explanation alright, but it doesn't seem to hold much water when it can be rectified in half an hour. I think anyone who knows enough to see the vulnerability can see the solution.