Experimentation confirms that an SQL Anywhere 16 upload_update written like yours (INSERT ON EXISTING UPDATE VALUES with the column name pairs matching in the INSERT and VALUES lists) properly handles an uploaded row from a remote where two columns appear in a different order.
However, the row on the remote is IMMEDIATELY DAMAGED by a download_cursor that uses the column order of the consolidated database to re-send the uploaded row back down to the remote (this can be quite a shock :-)
So... it may not be the upload_update doing the damage. If you query the data AFTER the synchronization, you may be seeing damage done on the remote rather than the consolidated.
The bottom line here: The order of columns in the download_cursor script MUST MATCH the order of columns in the remote database. You can achieve that by (a) changing the column order on the remote like you are doing, or (b) creating two sets of MobiLink scripts that differ by the order of the download_cursor SELECT list. The two sets of scripts are identified by different 'version' strings, and those version strings can be specified on the dbmlsync.exe command line when launching a sync.
The script version feature is one of MobiLink hallmark features; it allows a variety of different remote schemas to synchronize with a common consolidated database.