Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.
I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user).
Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server).
I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win".
Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).
As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that.
If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.