It would be good to have maxlag parameter values and rejection rates in statsd, to make it more obvious what is going on when there is replication lag, as in T198049.
About 10% of all API requests contain a maxlag parameter, so the rate would be substantial. Most of these are due to client libraries sending maxlag=5 by default. It's not really necessary for server protection to use maxlag for read actions, but I'm not sure if it's worth trying to change the policy.
We could break it down by module, say api.<module>.maxlag.accepted and api.<module>.maxlag.rejected, that way we could correlate the action=edit statistics with any observed drop in edit rate. We could send the maxlag parameter value as the statsd value so that we can predict what the rejection rate will be for any given replication lag.