The files in /boot are suspect to updates as any other file from any other package. If you just chroot into the broken system, mount the newly formatted /boot-partition and install the kernel and the bootloader you should get the newest kernel and bootloader packages. No need at all to install a whole system, although that approach also should work, if you also copy the kernel modules for the kernel version that comes with a fresh install. Partition sizes and partition type/partition table type do not matter.

A freshly installed Slackware system id about 7-8GB, when I made my modifications I usually land about 9-10GB. Since Slackware has an everything-and-the-kitchen-sink approach I would think that an Ubuntu install is much smaller (the system requirements mention 5GB disk space as minimum). Seeing that the total storage size in your system is 5TB, is size of a backup really a concern for you?
There are different techniques of backup. On Slackware I make a total system backup when I had major upgrades or big software installs, because Slackware is, when it comes to software that is not part of the standard installation, a mostly source-based system which involves sometimes a lot of compiling. Using rsync, this is not really a long procedure that can run in the background anyways.
On Ubuntu I would go for a different approach, I would backup the files in /boot, /etc and of course the configuration files in my /home directory. Then I would use dpkg to get a complete list of installed packages, so that I can simply re-install if needed. This procedure, when done on shutdown, should not last longer than a few seconds. I have done it that way when I was using Debian as my main OS (although I rather do my backups manually, not automatically), when I borked my system setting up a new one was a thing of about 15 minutes (I used network based installation with packages cached on a separate server).
Any backup strategy must be tested, so that the "probably" in your statement is non-existent. Ironically, Murphy's Law is not predictable and hit you directly while not having a backup. A proper backup of your /boot-partition would have solved this issue in about 5 minutes.

Of course you should always have at least one backup copy of your valuable data, otherwise Murphy can hit you here also. I keep copies of my valuable data on at least one extra machine at home and one off-site.

Okay, I just bought another 2TB drive, and need to decide what approach to take.

Is there any reason I need to install 12.04 again, or can/should I just install 13.04 at this point? I guess the main point of my question is this. For practical purposes, pretty much everything I can think of that worries me on my now-defective 2TB drive is:

- codeblocks IDE with all the various configuration files.
- thunderbird email system with about 15 email accounts and tens of thousands of emails.
- a work-in-progress firefox extension, including the associated firefox development profile.

Of course I also have lots of .txt files, .pdf files, .jpg files, and other files that are standalone and not subject to configuration files or special applications. Of course I have lots of .h files, .cpp files, and other application in my /home/max/project directory, but all these I can just save and replace without application configuration worries.

If you want to keep your configurations, I don't quite get why you want to do a reinstall at all, since we told you already that it most likely is not necessary. Why don't you just try to restore your boot partition in the way we described in previous posts?
If you really want to keep your configuration, even if you have to reinstall, I would definitively opt for 12.04 (which will give you support until 2017) instead of 13.04 (supported until 1-2014).

What I would do, just to be sure:
- Make a copy of your installed system to the new disk, just in case
- Try to repair the old one the way we described. If you need help with that just ask, we are here to help
- If that does not succeed, make a fresh install of 12.04 and install the latest updates
- Copy over your configuration files

The primary reason I consider creating a new installation is... the steps you guys tell me to do are not something I know how to do (though I basically understand what those steps mean). I'm fairly sure I'd screw something up.

However, if someone wants to give me step by step commands like eSelix did before, I'll give it a try.

Until I hear back from someone with these steps, I'll just install 64-bit ubuntu v12.04 on the new 2TB drive I just purchased (and copy my entire /home directory (and subdirectories) across to a backup directory on the new drive). Once I see the instructions, I'll try to fix the currently defective drive.

Before installing new system disconnect all not need drives (leave only new). I had situation, where installer modified boot sector on wrong drive (actually it was my fault, but it should ask me which device to use).

Be sure to copy hidden files and directories from /home. You can also backup your old /etc, /usr/local, /opt, ... - depending where you did your own modifications.

Remeber that if you have connected more drives, then, without additional configuration, device names sda, sdb... can be assigned to different drives each time, so be sure which drive you operate.

For repairing, preffered is to disconnect all drives and connect only this malfunctioning one and other with working system (it can be LiveCD or LiveUSB), then you can try to recover old disk. Assuming it is /dev/sda1 you can do:
Then disconnect drive with working system (or remove LiveCD) and boot from new system. Let us known if everything went well.

If I understand this right the hard drive that doesn't work has a small boot partition on sda1 and a Ubuntu root partition on sda3. If this is true reboot the bad hard drive and at the grub prompt try the following to see if it will boot.

If so once inside run sudo install-grub and sudo update-grub to reinstall grub.

This will only work if the filesystem on the /boot partition isn't corrupted, which sadly is the case here.

What I'm thinking is maybe the grub files got put on the root partition with what ever update that was done and the grub in the MBR is still looking for them in the boot partition. If this is true then this should work. I had something like this happen to me at one time.