Using the new encrypted filesystem on a daily usage should be trivial after the complicated way of initial setup. Once mounted all operations should be transparent. The overall performance of an encrypted filesystem is a bit worse compared to an unencrypted of course, but not noticeable on regular use. Loop-AES will scale well as long as you do not access large datastreams all the time like handling and editing large videofiles. However, there are some caveats and some security ideas you should have in mind.
If you are lucky owner of a notebook which is capable of doing "save to ram" with APM (Advanced Power Management) there is an issue with netfs, at least on RedHat 9. If you do APM suspend you might discover that your /home won't be mounted any longer after resuming. The problem might be triggered by other events, because of an issue in /etc/rc.d/init.d/netfs.
Whenever a suspend event occurs Redhat's apm-script triggers a stop of all network filesystems. Unfortunately also all loopback devices are detached and shut down. To prevend this you can either patch /etc/sysconfig/apm-scripts/apmscript to not call netfs stop or /etc/rc.d/init.d/netfs to not shutdown the loopback-devices. I think the last solution is the cleaner one, just comment out all lines in the stop section of that script, starting with "Unmount loopback stuff first" and ending just before the line "[ -n "$NETDEVMTAB" ] && {".
Suspending is possible by using ACPI or APM, or using one of the software methods like Software Suspend or Suspend 2. Doing a "save to disk" using these mechanisms might be a security concern, since Loop-AES or dm-crypt has to hold the encryptionpassword in RAM and so that would be stored on the harddisk (in cleartext!). Depending on your paranoidity you want to delete it on resuming. However this might be complicated and expensive (overwriting 512 MB for example with randomdata consumes a lot of time). However, even if you overwrite that part on the harddisk on resume, a clever attacker could make an image before resuming, or switch to standby again (if he has the possibility to trigger this, by pressing the power button for example) causing the RAM to be saved on the harddisk. To be sure you should work around this by disabling that kind of suspension. Software Suspend 2 offers the possibility to encrypt the RAM image when it is written to the disk, so you should consider to do so.
It might be unlikely that somebody steals your computer while working on it. A more realistic szenario is that your computer gets stolen on your absence. Beside from the material loss you have to make sure that your data is save, otherwise the encryption will be useless. Shutting down the computer is a total safe way, since that would prevend unauthorized access to the encrypted partitions. Nobody without the passphrase can mount these partitions. Removing the memorydevice with the keyfile and keyrings improves that even more. However, this is not the appropriate way in every case. Shutting down just when visiting the bathroom is overkill. If you use the "suspend to ram" feature quite often, like I do, you want your session restored quickly on resume. All this will be safe if you just take some security measures:
RedHat 9 does not ship xlock with its distribution any longer. You can either use xscreensaver -lock instead, or install xlockmore on your own. For Redhat 9 you can also use my xlock-binary which is compiled without PAM and shadow support. It will ask for a password the first time you use it and store it in our home directory (encrypted).
Resizing a Loop-AES or dm-crypt filesystem is painless, since Loop-AES/dm-crypt does not care about the size of the underlying device/file. Just unmount the filesystem, do the resizing and remount it (you should considering to make a backup first). With LVM, the logical volume manager and ext2/3 this is simple. For extenting just call lvextend first, then use losetup -F and glue to encrypted device to the unencrypted loopdevice, and finally call ext2resize. Afterwards your partition can be mounted as usual. Shrinking works the other way round, first ext2resize on the loopback device, and then lvreduce. Do not forget to call fsck before and afterwards.
Having your datas encrypted does not mean you don't need backups of course. Making backups should be nearly the same as before. However you could consider to save the backups on encrypted space too. Just create an encrypted partition on the server you backup to and mount it just before doing the backup and unmount it afterwards. An other way is to backup the whole encrypted file/device. If you can trust the server you backup to and just need the encryption on your notebook a standard backup to an unencrypted space might be enough.
At last you maybe want to know how to mount /home on startup.