less efficient than on duplicate key update because it will replace the entire row every time. But that's not any worse if you were going to do that anyway manually.
We have people write scripts that populate data in our database keep a set of IDs around that they want to delete and if they have new data to insert somewhere along the way we have them update the rows they were going to delete with the new data they were going to insert. We insert and delete data only as we need to. Doing this to 3-4 tables that have high contention cut my slow query log size by half and all the queries that I don't see in that log anymore impact customers so it was a great change.
As kind of a sidenote to anyone using these features, I would recommend that you regularly run mk-table-checksum against your master/slave databases.[1] This will tell you if there's inconsistent data between the master and the slaves. Depending on the type of error, you may not get replication errors when tables get out of sync, and this tool catches the case where no replication errors occur (e.g. UPDATE that modified data on the master, but failed to modify data on the slave). Running this, or a similar tool, is really the only way to know that the queries you're running are safe, regardless of Internet hearsay or what the MySQL bugzilla says.