I agree that it is nicer to maintain a description, but what you are basically doing is a database diff between the current database and a description snapshot. I think that is very dangerous and something liquibase was actively designed to avoid (See pre-liquibase 1.0 blog post http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html)
I think the “database version control should be like source version control” is an easy and natural assumption devs make, but database changes requiring a semantic meaning of what changed, not just a syntactic meaning is extremely significant.
That is why I think it is best to have a change set built up of descriptive steps. It not only preserves the intent of the change, but it also ensures that all current and future database updates follow the same flow which allows you rely on past QA testing of the update process.