I really like this article and the Google blog post you mentioned. It makes sense, a lot of sense. It's brilliant, in fact.
But I think you made a mistake. The Google blog post didn't suggestion rolling back the change in the database schema. Quoting from the blog post:
Now, if there are any problems with either of the new binaries then you can roll back to a previous version without having to also roll back the schema.
Using the Google blog posts terminology, version v + 1 of an app takes into account only the changes to the database schema, without adding any new functionality to version v. Then you apply the database schema changes, and then introduce the functionality changes to the app in version v + 2.
However, you bring up something I don't think was necessarily taken into account in Google's blog post. That's how might things be effected if you drop some database object, like a table, view or stored proc? It almost seems to me as though Google's post covered only adding something to a database schema, rather than removing something big like dropping an object.
Still, I really like Google's approach on this and it certainly covers what likely is the majority of database schema changes.
True, but if the issue is with the database, you can roll back the schema changes without breaking the app. You're also not under pressure to roll back changes in the db because users must wait. You can do this in a more controlled fashion.