The retryable reads spec says:

Any driver that provides generic command runners for read commands(with logic to inherit a client-level read concerns) SHOULD implement retryability for the read-only command runner.

And it explicitly says not to prevent mapReduce from retrying if executed through generic read command helper:

N.B. If mapReduce is executed via a generic command runner for read commands, drivers SHOULD NOT inspect the command to prevent mapReduce from retrying.

But getMore does not have the same note. I think we should be retrying getMore in this case (i.e. not inspecting the command). Though as suggested by shane.harvey perhaps we should update the generic read command docs to warn than getMores will be incorrectly retried when retryReads=true.