My company uses SQL Toolkit to automate SQL Compare in an application we use to distribute schema changes to our clients when they upgrade to a newer version of our product. It works quite well for this.
We did have to write our own data synchronization due to limitations with SQL Data Compare at the time that the tool was written, mostly due to problems with our database schema, such as the lack of proper keys. We also wanted additional logic on how to identify the records in question and what to do with a record if it already existed. It's possible that SQL Data Compare does handle all of this now. For example, we might identify a record by a combination of two VARCHAR fields that are not the primary key. If the record already exists we might optionally overwrite the contents of some of the other fields of that record with data within our snapshot, but leave the over fields alone.
The one area we had a lot of problems with SQL Compare is that the level of granularity on differences does not go any deeper than table-level. For better or worse (definitely worse), our software is sold with the idea that the client may alter the schema. We now try to discourage modifying the tables that we ship and keeping schema changes to custom tables, but some of our clients still have and rely on these custom changes. By default SQL Compare would drop these extraneous columns as they would not exist in the model snapshot. In order to overcome this, and several similar situations, I had to resort to .NET reflection to add those extra columns to the underlying object model of the database snapshot so that SQL Compare would think that those columns belong there and would not touch them. This is certainly a fragile solution and I fear that an SQL Toolkit upgrade might break it. I would really like to see built-in support for being able to ignore differences down to the column and index level, or maybe some supported way of modifying the snapshot in code.