My steam install is on a Crucial RealSSD C300 256GB SATA III and it hasn't locked up for any more than a small handful of seconds.
After my TF2 map load times were getting tedious, I checked the .gcf files with filefrag and found some of them had as many as 2000 extents (read: very fragmented). Loading was somewhat faster after using a shell script like so (which reduced the largest gcfs to 16 extents and most gcfs to 1 or 2), so it does make a difference:
#!/bin/sh
# Usage: ./defrag.sh "file to defragment.gcf"
SIZE=$(stat --printf=%s "$1")
FILE="$1"
OFILE="$1.bak"
mv "$FILE" "$OFILE"
fallocate -l $SIZE "$FILE"
dd bs=200M "if=$OFILE" "of=$FILE"
Nothing extracted yet.
So far as I can tell, Steam currently uses the "standard" application-managed, zero-write form of preallocation to initialize new games upon install. This results in saturation of the target storage's write throughput, which can cause serious performance issues, especially for larger games.
Case in point, I went to reinstall TF2 from scratch today (to attempt to resolve some performance issues I've been encountering). When the installation started, Steam preallocated the entirety of the 12GB that TF2 would download to disk.
This mean that for upwards of two minutes, my system was nearly unresponsive, due to the disk being saturated. I'm not sure what it's like for people without an SSD, but I'm sure it's worse.
Modern filesystems like ext4 (and later version of ext3) support persistent preallocation using the new fallocate call. This provides a kernel-managed pre-allocation of the disk space needed by the game, guaranteeing its availability, and also coming with the added bonus that it'll likely be as contiguous as is available (since it's an allocation made all at once, rather an an allocation that is made over the course of multiple potential flushes).
I've not done any actual reverse engineering of Steam's installation process to verify what I've said, but rather came to it through some educated guessing based on what I was encountering in terms of disk saturation. Let me know if I'm wrong in my assumptions. :)