Good examples of using system tables.  I would use information_schema views except that not all of the information available via system tables exists in the views; and for that reason, I prefer to just be consistent and always use the system tables.

I don't like the conclusion though - that it isn't necessary to save scripts but rather rely on a "source" database and use system tables to push objects to "target" databases.  While that might correctly copy the objects, the developer is left with no change history, no way of rolling back to previous versions, no way of commenting about changes, no way of grouping objects together logically and labeling them as a release, and the "target" database must be reachable from the "source" database.  I realize that it is more work to manage SQL Server objects as scripts, but I believe configuration management can be much more robust by doing so.