There are a number of key things that mean that a hard drive can be the reason behind a buffer under-run.
The hard drive used to use IDE cables, which could mean that on one cable you have data being copied from the hard drive and then written to the CD/DVD drive. This would effectively halve the available bandwidth to or from each device. While this has changed with SATA there is still contention in the SATA bus controller. This leads into my second point
There may be programs trying to do things at the same time, another program reading or writing any substantial amount of data can again limit the bandwidth to either of the devices in a similar way to the first point. An excessively large sequential read could well completely block hard drive I/O for seconds or longer.
The operating system being low on memory will mean that it needing to page other programs in from or out to disk, causing large sequential reads or writes to the page file that can block I/O as in point 2.
All these things mean that whatever theoretical peak bandwidth you think you have is not available all the time.
The problem comes when your CD-writer absolutely has to have guaranteed bandwidth between the hard drive and CD-ROM, if that bandwidth is starved for more than a second or two (the typical buffer size on a CD-writer) then a buffer underflow will occur. Programs or the operating system demanding use of the hard drive is enough to interrupt the flow of data to the CD-writer for long enough to cause this to happen.
The main reason that we recommend substantially faster hard drives to prevent buffer under-runs is because a faster drive will be able to get past the blocking I/O much faster and back to the task of reading the data to be sent to the CD-writer.
-=EDIT=-
You are right that a lot of inexperienced users would have a large number of "helper" applications (RealPlayer, quickstarters and other assorted near-malware applications) which meant that there was less memory available. Older home user systems generally only had enough memory available for the OS and a program or two to be run comfortably, add in all the useless garbage programs and the CD-writing software needing a large buffer of its own and "comfortable" amounts of memory become decidedly uncomfortable.
Also note that anti-virus software can also have an impact on hard disk bandwidth as they have to scan every bit of data coming from the hard disk. Freeing up resources by closing those programs and clearing the system generally allowed the CD-writer to get on with its job.
The main thing that makes an underrun actually a thing to avoid at all costs though was the way the CD-writer actually writes to the drive. The laser, while writing, is dumb: "I have data in buffer, I write data".
It is not written block by block, even though a CD is written in sectors, the writing process is done as one long track and the laser simply outputs what is in the buffer to the sectors on the disk. If the buffer on the CD-writer suddenly is not getting updated with new data (as the system is doing something else) then the same data in the buffer will be written numerous times, without any sign from the controlling software that it should have stopped writing data long ago, and you end up with garbage on the disk. It could be several hundred megabytes of garbage or it could just be a few kilobytes, either way that disk is now worthless as it is impossible to tell where the good data ended and the bad data started.
Recovering from the garbage being written is difficult, as you have no way to tell just how much of the data written really was garbage and how much of it really was meant to be repeated. It would be much better if we could prevent the garbage being written in the first place and this is what the under-run protection is doing, it watches the buffer and when it gets near to being empty it will tell the laser to stop writing and wait for fresh data to appear before continuing on.