1) there is a replSetMaintenance command. couldn't one just use that instead?
2) if this "secondary stepdown" makes sense for this command, isn't there a several other dba commands that would also perhaps, yet we don't, so there is inconsistency?
3) if this is the only secondary that is up, does it still go to recovering? what behavior would be appropriate then?
3b) if going to replica would cause a loss of w:majority for the set, does it still do it?
4) replSetStatus should explain why it is in recovering if this is happening, to avoid longer troubleshootings, does it?
5) one thing that would be nice is if replSetMaintenance would take a parameter that is a command to run, and then when done the maintenance mode ends automatically. this would prevent accidentally getting "stuck" in that mode. you could imagine that happening if 100 shards are scripted and one of them flaps or something. i.e. :
runCommand(

{ replSetMaintenance : <any_cmd> }

)

btw feature request : it might be nice if replSetMaintenance, you could say if your expectation is there are other secondaries up (either for reaidng or so that primary failover still possible), or that w:majority will still hold. another approach would be the result from the command, if using the existing form

{replsetmaintance:true}

, could return info:"ok, but there are no other secondaries at the moment" or something like that so user might say oops and then quickly revert...

WARNING If you run touch on a secondary, the secondary will enter a RECOVERING state to prevent clients from sending read operations during the touch operation. When touch finishes the secondary will automatically return to SECONDARY state. See state for more information on replica set member states.