A little about what you're doing and why:
I assume you know why you want to root your phone or you probably wouldn't be here to find out how to do it. This section will not cover that topic. What we will cover, briefly, is why you're doing what you're doing -- and we'll discuss the typical components of rooting an Android phone in the process. This was covered very very briefly at the top [of the OP] but will be covered slightly less briefly now.
For us, the first piece of the puzzle is the recovery partition. This is an area that contains the recovery system. The recovery system is most often used to flash updates onto the phone. Normally such an update would be provided over the air (OTA) by your carrier, and after you accept it, the (recovery system of your) phone would install it. Most "stock recoveries" (which is how we refer to the original recovery system on the phone when it is new) will only install updates that have been signed by your carrier (or another trusted entity). There are various reasons for that which we shall not cover here. If we want to apply our own update (such as an update that will "root" the phone), then we've got a problem because your carrier doesn't want you to root your phone, so they certainly are not going to sign such an update, and if it's not signed, your stock recovery won't install it. So we need to replace the recovery with one that isn't quite so picky.
That's what the first part of the procedure (the part where we use RSD Lite to flash an SBF file containing nothing but a custom recovery onto the phone) does. Some pretty talented folks have written their own modified versions of the recovery system (the recovery system is open source so they had a good place to start) that ignores the signature checking and lets you flash on pretty much whatever you want. These custom recoveries enable other features too that we are not concerned with here. It is important to understand that, in order make our process work on any version of the OS (or "build" of the operating system, e.g. FRG22D) we want to replace only the recovery partition and not disturb the kernel, etc. The SBF provided in this topic does just that. It replaces your recovery system with SPRecovery, and nothing more. SPRecovery will then allow us to flash on unsigned updates which is how we'll "get root".
To "get root" on an Android phone you really only need a single file -- "su" -- with the right permissions. The operating system however isn't going to just let you put that file on there and grant those permissions, or else what point would there be in having permissions to begin with? Fortunately for us, when we boot our custom recovery, we're not running the operating system build that's on your phone, we're running the scaled back OS build that's part of recovery. And it is configured to let us have super user rights, and also happens to have access to the /system partition on your phone (which is the one we need to add our "su" file to in order to root it).
Now, if we just added su, and nothing else, we'd be rooted. Unfortunately, so would any other app that wanted to be. Any app that new to call su to try to "get root" would succeed and every app you ever put on your phone could do anything it wants. You probably wouldn't want that. So, the smart guys that wrote su for these phones wrote another utility called Superuser.apk. This piece allows you to review and approve (or deny) any requests for root authority, and, if you choose, it remembers your selection for next time. When an app asks su for super user rights, su first checks the database to see if the app is allowed to have those rights, and if it is, then it grants them, if it is explicitly denied to that app, it denies them, and otherwise it asks you what to do (and then denies the right if you don't respond before the timeout). Those two parts in combination provide an effective root control mechanism for the phone.
The last piece of the root puzzle is "busybox". In the Linux world (upon which Android is based) a lot of the tasks one may need to do "as root" are performed by one of dozens of external command line utilities. To save space and processing power, busybox was invented. It contains the most common of those utilities all in one executable. Then "symbolic links" (aka symlinks) are created to simulate the presence of the dozens of utilities as if each separate executable was there (when its really busybox pretending to be each of them and doing all the work). Many apps that require root will not function if busybox is not installed because they rely upon it to do what they need done. Some apps like Titanium Backup can optionally install their own copy to avoid this dependency.
While not technically part of the rooting puzzle, there is also the Flash Recovery Service (FRS). This service is installed by the OTA updates and is designed to keep your recovery partition from getting corrupted. Of course to your carrier, if you install a custom recovery, that is corrupted because it's not the one they want you to have. Each time your phone boots, FRS will check your recovery partition, and if it is "corrupted" it will attempt to flash it back to stock.
The update.zip in this procedure installs su, Superuser.apk, busybox, and disables FRS so that it all stays that way after each boot.