Correct me if I'm wrong, but you seem to be suggesting a stateless presentation tier. Thus the session state must be moved either forward to the client (i.e., browser) or backward to the middle tier or (as you suggest) database. Let's consider each of these strategies:
If you're putting the state in the browser as hidden variables, you *MUST* incorporate some mechanism to allow your app to detect whether it has been tampered with. Otherwise you are effectively giving a malicious user write access to their own session. Since the presentation tier is stateless, it has no intrinsic way to know whether the user has manipulated the session in order to, for instance, gain access to someone else's accounts. Encryption of the hidden variables would foil this kind of tampering, but at a cost in CPU cycles. Note that this encryption would have to be done *over and above* the normal https encryption because the two are serving different purposes: https protects the data from third parties, while hidden variable encryption protects the session from tampering by your own user.
If you're putting the session state in the database, this solves the security problem and provides absolute protection of the session even if the whole server farm goes down. For situations where absolute session preservation is mandatory, this is a reasonable solution. The costs, however, are enormous, because potentially each request/response cycle results in an additional database write. Response time increases because the user has to sit waiting on an additional write, while throughput declines due to the increased traffic to and from the database.