SERVER-41766 changed the catalog multikey update for multi-statement transactions on primaries to happen in a side transaction. This side transaction looks at the logical clock to find a timestamp far enough in the future to use for writing to the catalog.
Because (I believe) we only perform this ghost timestamp on primaries, it's preferable to instead write a no-op oplog entry. That way the stable timestamp never races with the transaction being committed. Durable history may have different consequences due to these races.