Ok so, for the first question: there are a few reasons to use a bash script for your cronjob:
As you mentioned, you can consolidate many commands in to one bash script. This is a lot more readable than just clumping together a huge crontab line, especially since the logic flow is more obvious. Compare:
command1 >/tmp/foo && command2 || command3
if command1 >/tmp/foo
Another reason to call a script in your crontab is so that you can call something besides bash. For example, you can invoke a perl script or even a php script.
Also, suppose you have some logic you want to call outside of cron. Then, it also makes sense to put that logic in a separate script installed on your server. You can run that script as needed on the command line, and you can also call it from the crontab.
Finally, note that quoting in crontabs is really weird. The canonical example is that crontabs eat the percent sign. If you put a '%' in a crontab line, you actually have to double it ('%%') or else cron will eat the bare percent sign and confuse the jebebus out of you.
Basically, wrapping a cronjob in a script is safer (more standard quoting/escaping) and more flexible. Any cronjob longer than one or two commands should probably be moved in to a separate script.
The second question is pretty straightforward: when you edit your crontab, you don't edit the file under /var/spool directly. Instead, the
crontab -e command copies your crontab file to a tempfile in /tmp. Part of the tempfile name is a random string designed to lessen the chance of two invocations of
crontab -e from trying to edit the same file in /tmp.
It's safer to edit a temporary file for various reasons. One is that if the editing process crashes, the original file is left untouched and usable. Another is that it allows the system to check the new crontab for syntax errors before replacing the old one.
Also I will be amazed if I managed to type this whole entry without saying cornjob once.