If you take away SLEEP, the attacker will exploit something else during their test. Better SLEEP than really badly customized DROP or DELETE statements to see if their last created resource is affected.
These are valid points, but don't necessarily reflect the reality of a production web environment whose user ONLY has SELECT access to read caches and view data from the database.
Being able to enumerate vulnerable spots or exfiltrate data can arguably be more devastating than performing a DROP that's noticed immediately and the LKG table from backup is imported to fix it.
One suggestion is to allow further segregation of permissions for functions like SLEEP, BENCHMARK, etc. A front-end request has no need for it.
It’s the exposition of things that “act” on lax query permission sets that “appear” read-only (but in fact have interrupt style executions) that leads to trivialization of abuse.
Why not monitor for SLEEP execution instead?