The cookies you mention are set by Google Analytics, they are usually set on a domain-wide basis to cover all subdomains.
Nginx cannot make a browser not send any cookies, there is not part of the HTTP specification that allows a web server to say it's not interested in cookies so a browser will always send them. Many of the biggest sites where this suggestion actually matters use a completely seperate domain for static files -- such as yimg.com for yahoo.
I don't really see it as a problem, as cookies aren't that big and the server doesn't have to send them back in the response. So while yes, one or more cookies set by example.com will "balloon" the request to static.example.com, static.example.com doesn't have to send it back in the response, so the server's response is completely unaffected.
Further, if you have content that you know to be static (images, CSS, JS, etc.), you should be setting proper cache control headers, especially an Expires header for some appropriate time in the future (e.g. +1 day, +1 week, +50 years, whatever makes sense for how often your static content changes). With this done, those cookies will only be sent one time, and then future need for those files will be handled by the browser's cache.
If you do still feel like this is too much (I can't really see how it could be, honestly), you can possibly mitigate it by using paths. For example, if your web app only needs cookies at example.com/app, set the cookie-path to be /app, and then requests to static.example.com/images/some-awesome-image.jpg won't send that cookie because the path doesn't match.
You can further mitigate it by reducing the number of cookies you use -- for most purposes, one (and only one) cookie storing a single session ID only adds a few bytes (less than 1KB in every implementation I've seen/used), and gives the server ample information to look up everything it needs to know about that client server-side.
Honestly, if you're worried about short-URL domains making your site non-future-proof because of cookies, then I think you have an architectural problem with too many/too big cookies, and you should re-evaluate your strategy from that point of view.
Best Answer
I don't think apache can be the enforcer here. Even the RequestHeader unset option above will only happen after the client has sent the request with the cookie.
The key thing here the google page speed tool is noticing is that the client sends the cookie on the request. That means somewhere in your application you have set a domain.com cookie (so in effect, *.domain.com). You need to carefully only ever set www.domain.com (or whatever subdomain you're using) in your cookies code. Truthfully, most professional websites wind up with so many third party widgets and javascripts and browser calls that its easier to just abandon your "main" domain for this and setup a full second domain that will never ever have a cookie set on it. You can see facebook does this with fbcdn.net. Huffingtonpost.com does this with huffpost.com.