Δεν ξέρω τι κάνει και πως το κάνει η σελίδα του Πλαισίου ή μάλλον οι developers που έφτιαξαν τη σελίδα του Πλαισίου και είναι λίγο δύσκολο να υποθέσει κανείς αν δεν δει το source κώδικα. Γενικά, το ViewState είναι ένα από τα πιο misused χαρακτηριστικά του ASP.NET και ως εκ τούτου υπάρχει πάντοτε η πιθανότητα η όποια σελίδα να έχει τεράστιο ViewState που να έχει προκύψει από κακή (ή μη-optimized) χρήση του.
Από την άλλη μεριά, σε ό,τι αφορά το scalability, σε μια ολοκληρωμένη εφαρμογή που αποτελείται από πολλά tiers, μία λύση (όπως η χρήση queries αντί ViewState) που μπορεί να δουλεύει καλά σε μια δεδομένη χρονική στιγμή ή σε ένα δεδομένο περιβάλλον, μπορεί να μην δουλεύει καλά σε άλλη χρονική στιγμή ή περιβάλλον (όταν για παράδειγμα το RDBMS έχει φτάσει σε near capacity φορτία). Γι αυτό κι έγραψα ότι κάθε επιλογή έχει trade offs. Η δική μου προσέγγιση στο πρόβλημα θα ήταν να μην απαρνηθώ το ViewState (εξάλλου προσφέρει ευκολία, όπερ σημαίνει γρηγορότερη υλοποίηση, όπερ σημαίνει μικρό κόστος (ή μεγαλύτερο κέρδος - εξαρατάται την οπτική γωνία 
) αλλά να βεβαιωθώ ότι κάνω σε πρώτη φάση σωστή και σε δεύτερη optimized χρήση. Κατόπιν να ελέγξω αν υπάρχουν προβλήματα στο performance και να δοκιμάσω την εναλλακτική λύση του database reload.
Ρίξε μια ματιά εδώ: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx καθώς επίσης κι εδώ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/viewstate.asp (αναφέρεται στο πρώτο) ιδιαίτερο ενδιαφέρον έχει το σημείο "Specifying Where to Persist the View State"
Vir prudens non contra ventum mingit