4kb viewstate wouldn't require not even optimization. There must be something stacking up then. Maybe when you add custom modules then the will add so much overhead. It may be due to "bad" coding or because those modules really leverage viewstate for something. But sites I'm working are about 60/80k that is not outrageous, yet if I can move those non-client-cacheable 60k away from the client/server pipeline and bandwidth I'm still happy. Consider a 25k pageviews is 1.5 Gb bandwidth just for the viewstate and the added overhead in page load times considering both the upload (since it is posted back to the server) and the download.
Overall is a server-only value it shoudl stay on the server and be tied to the user with an id just like session.

Yes exactly Cathal, but memory it's not the best place for this in my opinion... better to reserve this for caching of modules and page to avoid dozens of sql query, while file system/db are the first choice (viewstate in db would be a single query after all) or distributed cache in a wider scenario. Also using disk/db allow for a longer persistance of the viewstate without having to worry about keeping memory resources busy.
Having the viewstate on the server is also added security since it avoids tampering (even if in a well designed scenario you won't keep security data there).
About the "ajax" issue when you move away the viewstate this is just matter of using the ScriptManager.RegisterHiddenField instead of ClientScript.RegisterHiddenField to add the "revised" viewstate field with the ID.