Either way is OK with me, but I'm not wholly clear on its intended audience. The SLOT_MILLIS_* counters are useful to operators and developers, as they provide information about the efficiency of the scheduler: they're useful for bottleneck analysis of repeated sets of jobs, tuning of the aggregate cluster, and comparing different runs of concurrent pipelines. By only accumulating the time that was actually spent doing work, the proposed counters could measure the efficiency of the job and be useful to the user, for tuning parameters like slowstart (a long shuffle time for small amounts of intermediate data might indicate that the job is scheduling reduces too early).
Most of the framework counters (FileSystem, framework bytes and records) provide feedback to the user, to help determine if their job is written correctly and tuned efficiently. This is slightly different, because it's not a property of a particular MapReduce job (e.g. a job where every reduce fails once could look "efficient" by this metric). I guess my question would be: if this information is presented in every user job, then how should (s)he react to it? If it's not user-centric and only another presentation of data the operator already has, then it seems less motivated to me. All that said, the cost is low, so if you feel it's useful then I've no objection to it.