This can't be the default because you can't assume that every user is going to have tons of RAM and a 64-bit OS. Also, you eventually want to sync up cache to disk, so that you don't lose your entire cache when you shut down Firefox or your computer.
I think a better approach is to leave the cache on the filesystem, but to use a smarter filesystem driver that can receive hints about files that have low priority to be synced to disk, so that many changes can be accrued in memory over a long period of time without the changes being committed to physical media. This would provide performance comparable to a RAM disk without having to modify the application at all.
If you're on Windows, you might be kinda stuck unless you use a third party filesystem driver (or try ReFS in Windows Server 8; not sure if it does delayed commits). If you're on Linux, you can try certain features of ext4 such as delayed commits and delayed allocation; you can also disable the safety feature that prevents files from being committed to disk until fsync() is called on them. This reduces data safety in the general case, but for a cache, you really don't care if you lose the data due to a random power failure, right? It's not valuable data, and you're more interested in performance than data integrity. If the cache is corrupted then FF can just delete it and start over.
As for my original idea of a filesystem that can take a "hint" that certain files are not valuable and don't need to be committed unless there's memory pressure to push the pages out from memory: that would be nice but I don't know if any active FSes on any platform do that. Sounds like something that needs to be added to the POSIX standards. Most filesystems today violate the standards by automatically syncing data to disk every N seconds (usually 5 - 15 seconds) even if the program doesn't call fsync(), so now we need a way to tell it, "whoa whoa wait a minute, I really don't care about these files and would rather you NOT sync them unless the system is shutting down". Filesystem design detail though... not sure if you're into that kinda stuff :)