1) Official root methods (see `fastboot oem unlock`, as made famous by the Nexus phones) as well as many less official methods require a wipe, thus rendering this attack moot.
2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases.
It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation.
And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.
But, if you're rooted, you likely have a custom recovery and bootloader which will accept commends freely, so it is pretty trivial to pull arbitrary stuff from the phone. You should, however, be safe from other routes, so long as you disable adb (which also freely accepts commands as root in most ROMS), Filesytem encryption would close all these attacks, but I'm not aware of any particular implementations (I'm pretty sure there aren't any popular ones)
Not only does the custom recovery in itself open up a hole, if you've made full-device backups with root tools, those backups will be sitting on your microSD card totally unprotected. Clockwork essentially dd's your NAND, and Titanium will leave a folder of conveniently named sqlite files ready for the taking.
Plus, "detecting" a rooted device is rather easy depending on how extreme your changes have gone. Seeing the AOSP lockscreen or a status bar that doesn't match the OEMs skin is a dead giveaway that the phone's been rooted. With that in mind, an attacker could simply pop open the battery cover, remove your SD card, replace it with a blank (so you don't notice the 'missing SD card' warning), and put everything back together in under a minute. By the time you notice something's up, the attacker will be long gone with your card full of plaintext backups.
PS: even if you don't keep backups on your device, merely having Clockwork installed makes the act of an attacker getting one (while bypassing your passcode) trivial. The attacker simply needs to power off your device (yank the battery), insert his SD card, reboot your device into Clockwork (on HTC phones, this is vol-down + Power), run a backup, remove his SD card and replace yours, and reboot again. This can be done in the space of 5 minutes, and you will never know unless you pay very close attention to your phone's uptime. And of course, how do you know your phone wasn't just having a bad day and rebooted of it's own free will?
Full device encryption is part of the Android platform as of 3.0; besides that some OEMs (I believe Motorola is one of them) have taken the liberty to implement it themselves. As well, Whisper[1] has produced a solution for the Nexus phones.
Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say.
And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`.
Wait... so Android could run processes with root privileges without asking you? Whoa!
Now consider that adbd on a rooted device runs with root privileges...
Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run.
Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are gatekeepers to uid 0, which short of bugs, you can't get around.
Also, did you know, that you can disable adbd? Or remove root privileges from it?
2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases.
It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation.
And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.