A lot of other commands require parameters that the attacker may not know the values for. Those require more knowledge about the system that first needs to be exfiltrated. Not every (hacked) query has its output directly plastered back in the UI, webpage or API response. So that would need more hacking, even if the "sleep" tells the hacker they're on to something. Disabling "sleep" would take away the canary, would it not? Maybe the hacker isn't even interested in dropping tables.
Disabling sleep would not take away the canary, it would make it more inconvenient - every instance of sleep can be replaced with some convoluted query that does a very slow calculation.
Not quite true - there are permissions around other operations.
Yes, thank you - since the most "secure" method of generating UI/UX while still depending on a database at least requires SELECT permission, even if INSERT/DROP/DELETE are enabled, having SLEEP() not require special permissions makes it trivial to use in vulnerability enumeration.