I have read that the usual way of handling login sessions is by storing a long random string server-side and setting a cookie with this string as its value.
What are the reasons why one shouldn't try to eliminate the load on the server by using a different method. The method I'm most concerned about is storing a cookie containing info about the logged in user (and session, etc...), and ensure the authenticity of the cookie by signing it instead of persisting cookie-specific data server-side.
Done properly, this can be just as secure as the random cookie solution. It can be a bit harder to get right though. (Remember, you can't store secret values in the cookie.)
However, done properly, it may not reduce load on the server either. While you no longer need to look up (some of) the session information, you do need to perform cryptographic operations on every request to validate the cookie. (This can be very CPU expensive.)
When I built a solution similar to this several years ago for a system that didn't support sessions, the cookies consisted of both the data (which was encrypted with AES128) and a Message Authentication Code (HMAC_SHA256). Only after it underwent significant security review were we comfortable deploying it.