Yes, what you propose is definitely desirable. However, if you look at the database schema you will notice that SKU is not actually a key of the uc_products table (represented by the "model" column). Despite its connotation, the SKU does not actually uniquely identify a product in the crucial uc_products table. There is nothing in Ubercart to stop you creating many products all with the same SKU - try it.
The only guarantied unique identifier for a product is its Drupal "nid" which I have called Product_Id in an attempt to avoid jargon. The import code does check that the SKU matches the "model" field on import, and will report a warning if there's no match, but that's just a safety check. Updating by SKU without a SKU key would also mean that updates would be slow for a large store.
However, all is not lost. You could probably do some kind of relational join or lookup type operation in your spreadsheet that would essentially merge the 3rd party and exported spreadsheets on the SKU field - once you'd satisfied yourself the SKUs were unique in the exported file. Remember, you can go to town with extra columns in the imported spreadsheet and the import code will just ignore them.
The reason why the stock level and price info is not exported in the same file also relates to database structure. In this case, SKU _is_ a key on the uc_product_stock table (called 'sku', not 'model' in this case - go figure... ), so can be used as a unique identifier, and (as far as I can tell) indicates the stock level for both product options that have "alternate" SKUs and products themselves. I guess it would be possible to include the stock level for products in products.csv, and the stock level for product options in product-options.csv. Hmm... I'll have a think about it.