[Galaxy S III Q&A, Help & Troubleshooting] qwerty12:
'K, I'll bite. I'm not going to give an overall recommendation - at the end of day, they both install an APK and put a new binary in /system/xbin.

Note: I used CF-Root to root my phone. When I talk about how the the toolkit does what it does, I'm basing my words on this image. I've seen the things in that image before, even though I haven't used the toolkit. This also means that my toolkit observations may not be entirely accurate but it's a batch script, anyway; you can just read through it and find out how it works. I'm also primarily a Windows user, but I used to use GNU/Linux quite a bit to write programs for a phone that I once had.

Rooting is, when broken down, the installation of a "su" binary installed to /system/xbin, that is owned by root and carries the setuid flag. This flag is important as the Linux kernel will then run the process whenever it's invoked as the person who owns it, root. This process can then, in turn, start other programs and they inherit the user ID (something like this - I'm taking my time reading TLPI...) so they are then running as root. There's also a "manager" app (Superuser or SuperSU) that will be installed; this app is talked to by the su binary (through the Android Binder AFAIK, though Superuser's source is available so if you really wanted to find out you could read that) to see, for example, if the program that is invoking "su" is allowed to do so. CF-Root installs the SuperSU apk to /system/app, which means that it survives factory resets. The toolkit, from a quick look at the Superuser ZIP in its folder and its batch file, also installs the Superuser apk to /system/app. When sideloading apps or installing from the Google Play Store, they usually get installed to /data/app.

Not all "su" implementations for Android need a manager app, I've seen implementations where su does not place restrictions on who is allowed to run it; uid=0 for everyone without discrimination! (Yes, that also includes you, Super Smilies Pack 3000 with boob smilies) Thankfully, neither the toolkit nor CF-Root do this. I lie a little. Superuser's su binary will automatically reject any request to become root if the Superuser.apk is not installed but SuperSU's su binary will automatically accept all requests to become root if the SuperSU apk is not installed. Personally, I prefer SuperSU's behaviour as there have been too many times with my old phones where I'd have to sign into Google Play after wiping /data just to install the Superuser APK when all I wanted was to run a simple command.

ext* filesystems along with other *NIX filesystems have the concept of file permissions, a concept shared by other *NIX filesystems. In order to actually place this su binary owned by root into a folder owned by root, you need to be root. (Actually, the folder is also owned by the shell group so a user which is a member of that group could do it too, but they wouldn't be able to set the all-important setuid flag as they're not the user root [perhaps a member of group root could do it but I don't know]) Usually, exploits in other programs running/can run as root or in the kernel are searched for so that you can temporarily root in order to install the su binary correctly. The GSIII (with the exception of Verizon's) has an unlocked bootloader, though, so programmers don't need to search for any of these: it's able to flash unofficial, unsigned recoveries and kernels.

CF-Root does this:

* it flashes a new CWM-based recovery in the recovery partition of the phone. If you've seen the stock Android recovery, you'll know that it just can't match the features of CWM. The important thing about CWM is that it runs as root, just like the stock recovery, but it also lets you place any file anywhere on the phone without requiring that the the ZIP file containing the files are not signed with a Samsung private key. Remember what I said about file permissions?

* there's also a param.bin file. I don't know anything about this file, but I suspect it's flashed to get the phone to boot up into recovery mode the next time it's started so that CWM runs before anything else

* it also flashes the cache partition (I'm not sure whether it overwrites or appends as I don't know how [and probably never will] know how ODIN works with two ZIP files: SuperSU, which contains the su binary, the SuperSU apk and a script that is run by CWM to set the required permissions on the su binary among other things, and the CWM app which lets you tell the recovery what actions you want it to perform in Android without having to navigate through the awkward interface of CWM itself. While I don't know how to do this myself, CWM recovery can be told to automatically run commands from an external source. I'm not talking about random websites on the Internet, but (I think) through files that have to be placed somewhere by root. This is what apps like the CWM app and ROM Manager do. This is also what CF-Root does to tell the recovery that the next time it's booted that it should install both the CWM ZIP and SuperSU ZIP. That's it in the case of CF-Root: you now have a phone with the two files required for root access, and a CWM recovery and an app to control it.

The toolkit:

(I only talk about the "insecure boot" options as I imagine the recovery option does something similar to the above and do remember that I haven't used the toolkit to root my phone so some assumptions are made. I also assume you know what ADB is as I won't be explaining it)

* it gets you to flash a kernel image with a patched adbd that runs as root, so adb on your computer, in turn, is able to place files anywhere on the phone's /. File permissions make it so you can't just place adbd in its expected place (/sbin) as any user and /sbin is also mounted on a ramdisk part of the flashable kernel image so it would be replaced on the next reboot, anyway.

* When the phone is running again with the new kernel, it then tells adb (now running as root) to push the Superuser APK and the su binary into their rightful place and sets the correct permisions on the su binary so that it runs as root

* if you've told it to install busybox, busybox is pushed and a bunch of symlinks for all the applets that BusyBox supports are set up

CF-Root installs, naturally, Chainfire's SuperSu whereas the toolkit installs Superuser. I much prefer SuperSU (and I bought a pro license for Superuser long before I did for SuperSu). Superuser's interface is much better than SuperSU's and it's also open-source but I find that SuperSU works much quicker for me (Root Explorer actually popped up a message on my sister's freshly-flashed Xperia Arc S saying that Superuser can be slow if Superuser hasn't granted it root access quick enough - I've never encountered that on my Huawei U8800pro with SuperSU which has pretty much the same specs as the Xperia) and it can also log the commands an app is running as root if you're suspicious of an application.

You'll notice that ADB still runs as a normal user with CF-Root. You can use Chainfire's adbd Insecure app which will replace /sbin/adbd everytime the phone is started with his patched adbd which always runs as root, or you can just flash one of the many kernels available that already include a patched /sbin/adbd.

CF-Root also does not install BusyBox. You can grab one of the installers from the Play Store but what I do personally is kang a CM9 nightly build for the I9300 and take the META-INF folder and the /system/xbin/busybox binary and strip out most of the lines in the update-script leaving only the lines that mount, extract and create the symlinks for busybox and place the result in a new ZIP which is then flashed with CWM.

Your "cf-root for example is incompatible with rommanager" gripe is easily solved - just flash another recovery. CF-Root just packages a CWM Recovery, an app to control CWM and SuperSU. CF-Root itself is not a resident component, but the recovery and SuperSU etc. are, if that makes sense.