This is a case of "it depends what you are doing." Perhaps the "right" advice is to avoid SQL altogether and use memcache/redis/etc!
I agree with you that extra RAM will help a lot, especially if you are able to read the whole working set into RAM. Yes it will still have to write data, but if you have mostly reads then the writes will have no contention for disk I/O.
However disk performance is often a bottleneck on SQL servers and harder than other things like RAM to upgrade later (if you have a server that's not fully populated with DIMMs).
There were a number of comments about RAID5 being slow, but I would say this is not always the case, so be careful before making sweeping statements. Really high end servers with fast RAID cards and lots of BBWC sometimes go much faster in RAID5 (or RAID50 with >4 disks) than they do in RAID10...
Over the years I've personally experienced slow RAID5 arrays, but after benchmarking a DL360 G5 with 4 146G SAS disks in ~2009, we had to double check our tests. Indeed, the array went faster with RAID5 than RAID10 in nearly every test. BBWC and fast parity calculations allowed the server could use the 4 disks much more effectively as a RAID5 array than RAID10. Some of the tests showed 50% better throughput with RAID5, and nearly none were slower. The tests that were slower were only 5-10% off.
I would caution the people who make blanket statements that RAID5 is slow, everybody says it online, but it is simply not true in every case.