The main reason is that it isn't necessary: there's no real reason why you would create a new key for each message, because using one key for all messages is perfectly secure with modern encryption algorithms. While you can't use one key for too much data, with AES "too much" is 256 exabytes (that's around 256 million terabytes), which is far more data than you actually end up using a session key for. Using one key for a whole session doesn't make it relevantly easier for an attacker to recover the key, for realistic sessions.
I'm not sure what you mean by "deriving a key using Diffie-Hellman" or "encrypted using RSA," but I assume you mean renegotiating the key every message (i.e. both parties communicate to negotiate a new key; "derive" is an odd word to use, because it generally refers to something computed on one end without having to talk to the other end). Renegotiating a key for every message isn't done because it's a waste of time. Key negotiation takes a few messages back and forth, and is somewhat slow (it involves at least one asymmetric algorithm, and a common trait of asymmetric algorithms is that they're slow).
For deriving keys, while it's possible, there isn't really a need for it, and it again adds complexity. You can't derive your key for a message from the plaintext of that message for obvious reasons (the other end doesn't know that plaintext until it decrypts it with the key). You can derive a unique key for every message from a master key (this is common in payment processing systems), but it's not needed in typical communications, and it isn't done to make it harder to recover a transaction key (it's done so that recovering a transaction key doesn't let you decrypt all transactions).