In reply to James.

User and blog count are included in the check because there is potentially a future case where the updates may need to be targeted.

Blog count was originally there for WordPress MU, where the thinking was that multisites with large numbers of blogs would need special handling code if there was an extremely big database change. This is because each blog is stored in it's own set of tables, therefore the "upgrade" process needs to run independently on each of them. If you have a couple dozen or so, no big deal. If you have several thousand, then you probably want to do a different way of sending the SQL needed to alter all those tables.

User count, same principle. If your users table is excessively large or perhaps even split across various databases with HyperDB, then we probably don't want to send you an update that does a big ALTER to it, potentially taking down the site for an extended period of time.

So far, those numbers have not been needed for database upgrades. That doesn't mean they won't be. There was a change a while back that changed the size of the user_pass field, but testing showed that it was not a game breaker for the users table even on very large tables, so it wasn't needed. Other alterations, such as moving data to/from usermeta and such, might need special code for larger sites.

The data is not stored or used for anything else, if that's what you're asking. The API currently ignores it. It's a just-in-case measure, because you can't predict the future and upgrades are complicated by a huge number of factors.