De-duplicate rows in place vs de-duplicate on transfer
Is there anything wrong with overall approach of using staging
  databases to store "raw data", and transferring batches of that stage
  into a target, eliminating duplicates within stage and between
  stage+target during the transfer.


This is a standard and typically the best approach. Staging should be a fast, logicless "ETL" step. Get into your OLTP source systems, get your data, and get out! The only reason to spend time doing logic on the source query is if it will result in a total reduced load on the OLTP. e.g. Incremental logic on a 10million row table may result in a faster query and shorter locks than if you try and do a dumb load of 10million rows every execution.

If you don't have resource contention issues (like a flat file) you can still maintain this approach, such that all of your Transform operations occur in a DB and ETL tool for efficiency, maintenance, and consolidation of ETL logic. Nothing like tricking another dev by leaving a little key piece of logic in the staging steps while the majority of data transformation resides elsewhere.


  If the general approach is sound, are the above queries OK? Is
  "EXISTS" a safe clause for scenario 1? Is the ROW_NUMBER PARTITION BY
  and JOIN BY the some columns a fast way to avoid transferring
  duplicates in scenario 2?


I personally love Window Functions as they are performant with clean, concise code. EXCEPT is also, typically, a very efficient operator and you are likely safe using it. There's nothing immediately wrong with your approach, so I'd save optimization until it actually becomes an issue. Since you used the word "safe" just double check the rules and how they apply to your data - you may get unexpected results if you don't account for how EXCEPT operates.