RE: Steemwallet.com: How to improve security in a least authority way AND how "NOT" to roll-out such security measures.

Possibly valid for my script, but not really the point why I brought up the rate limit example.

Other API's that implement rate limits tend to use custom HTTP headers like:

x-rate-limit-remaining
x-rate-limit-reset
x-rate-limit-limit

Or simply:

x-rpc-window
x-rpc-retry-in

As a library author, these headers are something you can work with to implement proper client side rate limiting. You can run statistics scripts that run at exactly the server defined rate-limit speed. That means a script that used to run for an hour might run for 15 hours now, but it will still run. Graceful degradation.

There are established best practices for implementing rate limiting for a web API. Just picking a limit size and period that the client would normally be unable to guess and then start responding with 4xx errors for a period of time the client couldn't reasonably guess either is in no way graceful degradation. It is a disruptive roll-out.