Joining in at this point. We have some sites powered by Craft which need to get some updates. Its absolutely acceptable if the dev version is outdated regarding the content. Making content changes should not be our job, and we mostly work with placeholder and testing content anyway.
The whole next procedure is optional, so enabling this behavior with a config param (or auto-enable when using dev-mode) might be the best idea.
Best would be to write structural changes along with non-content-related settings like asset transforms, plugin settings etc into a file called "_migrations.sql".
Before pushing an update from "dev" to "production", you simply need to press a "increment database structure version" button which then renames the file to "migrations-($v+1).sql". Also the version number in the database gets incremented so the saved version number is directly up-to-date with latest migration file version number.
If an update then goes live, the production database will be behind latest migration file version and executes them like the craft migrations do, incrementing the structure version in database too. Database will be fully up-to-date at this point without overwriting or changing any entry or asset.
In combination with git we could put these migration files under version control so they get part of the commit without committing all the other trash that changed in the database while working on it.
As long as this is not possible from Craft itself, a dump must be made before and after changes are made and manually processed to create migration by hand, which also must be manually executed on production environment. Depending on the amount of changes this can be very frustrating and time consuming.
Making the web developers spend less time and struggling on daily problems would cause more time for more projects to be made with craft. A win-win situation on both sides.