It appears to be how things are done in a number of frameworks. In a bizarre parallel to mgkimsal's comment, whenever I've asked about it, I've been told I just don't get web programming.
To my mind, the term cookie implies some sort of opaque handle. I give it to you, you give it back to me. It doesn't contain data, it's just a handle.
A base64 encoded 128-bit number also solves the problem of "omg, our cookies are so long we need a separate domain for static assets to reduce our bandwidth".
Rails claims its CookieStore will "greatly increase the speed of the application" relative to other stores (the guide mentions a file store and a database store) [1]. The cookie is a base64 encoded hash serialization (i.e. completely reversible by the client), but "to prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie."
I've not seen or performed myself any measurements of these claims. I have seen it suggested that CookieStore is the default because it is simpler in not requiring a database table, and not for any performance benefit. Without measuring, I can only guess the difference is dwarfed by the typical page load time.
To my mind, the term cookie implies some sort of opaque handle. I give it to you, you give it back to me. It doesn't contain data, it's just a handle.
A base64 encoded 128-bit number also solves the problem of "omg, our cookies are so long we need a separate domain for static assets to reduce our bandwidth".