The current implementation of replicated slow operation logging, found in oplog_applier_impl.cpp finishAndLogApply() only logs very basic information about the slow operation: the BSON of the oplog entry itself, its wall clock duration, and its size.

For normal (client-generated) slow query operation logging, we also include a number of fields that are relevant only to client-initiated queries, like the read preference and the number of bytes returned. Finally, we include a storage section that includes information on how many bytes were read and written.
It is this last section that can be very valuable. I undertook a recent slowness investigation that turned out to be insert operations to a collection with very large multi-key index entries, and this could have been diagnosed a lot faster if we had the storage information in the replication slow logs like we do for regular slow log entries.