Back then, the biggest bottleneck for mediawiki was the replication lag (specially due to HDD, etc.) so MediaWiki exposed the load on the database via a parameter called maxlag. Many bots stop and wait if the maxlag is above 5s and many bot frameworks actually use that as a metric on the load of the system and set their sleeps accordingly (even though their actions wouldn't be a write action). For example, pywikibot.

Fast forward a couple of years later, the size of jobqueue was added to the maxlag value (divide the value of the size by a number) so if jobqueue gets overloaded, then bots also back off and let the system recover by prioritizing humans.

Fast forward a couple of years later, the lag to the wikdiata query service was also added to the maxlag value. Since lag of WDQS is not as important as lag as of replicas, the value of that lag is divided in a way that bots back off if the lag of WDQS reach ten minutes (i.e. every ten minutes of lag of WDQS translates to 5 seconds of core replicas lag).

I'd argue that currently the best indicator of the load on our systems is appserver saturation. If databases of one cluster get overloaded, the appservers saturate. If kafka brokers have incorrect cpu governer, the appservers saturate. Traffic patterns, appservers saturate. Bad weather? Guess what happens.

If we can expose that (and/or number of connections to the databases, the data is already there since we use it to trigger circuit breakers) as part of maxlag value, automatically many bots will back off even reads and that can be quite useful.

Some prior art: T221774: Add Wikidata query service lag to Wikidata maxlag and T194950: Include Wikibase dispatch lag in API "maxlag" enforcing