Disk encryption is about keeping data on disk encrypted at all times; writing back the decrypted files onto the disk would incur the risk of leaking that data (if the machine is stolen at that point) and would require re-encrypting it upon shutdown. Note that a typical mechanical hard disk reads and writes data at about 120 MB/s, so a mere 128 GB hard disk would take more than 15 minutes to be decrypted entirely, even assuming that the decryption process is faster than that and that the disk is the bottleneck. You certainly don't wait for 15 minutes when you boot your machine up.
All this implies that decryption occurs on-the-fly, when files are read. A consequence is that decryption occurs as long as the machine is up and running, so the decryption key MUST be somewhere in RAM, and stay there.
Similarly, if you modify some files and want to save them (so as to get the new files back after the next reboot), then the encryption key must necessarily be used.
However, there are (at least) two methods by which you could envision not to keep the key in RAM:
You could read and decrypt a complete filesystem into a RAM-based disk. There, decryption could be done once and then the key discarded. Of course, this limits the total filesystem size to what can fit in RAM, e.g. 1 or 2 gigabytes. Moreover, all writes will be discarded (conceptually, one could use asymmetric encryption to save modifications, to be incorporated into the encrypted filesystem upon next boot, but that's likely to be a significant design and development effort).
The TRESOR project aims at doing encryption and decryption by keeping the keys in the CPU registers, and not allowing these registers to be flushed to RAM. This is for defence against cold boot attacks, in which attackers can take a good view at the whole RAM contents but not at the CPU registers as they were prior to the attack. It has been noted that attackers that can do DMA can inject malicious code that extracts the keys from the registers, so the protection cannot be considered as complete in that case.
An important point to consider is that you use disk encryption to keep the confidentiality of your data -- but when you access your data, you still pull it into RAM in order to process it. For instance, if you look at the contents of some text document, then, when you look at it, the document data necessarily exists unencrypted in the viewer application space, and the graphic card memory as well. Protecting the encryption key is all fine, but if the attacker is assumed to be able to read your RAM then he may plunder the data directly. Therefore, concentrating on the whereabouts of the encryption key without addressing the larger picture of the data kind of misses the point. In most practical contexts, it does not make a lot of sense to worry about cold boot attacks retrieving the disk encryption key -- even with all the TRESORs in the world, cold boot attacks would still be almost as worrisome.