One or two years ago I experienced the situation when the rebuilding client libraries broke the authoring interface so we had to take some activities to fix it. However, usually issues like that should not happen, so if you rebuild all libraries and something broke, let Adobe know if you have problems when you click that rebuild button.
This mechanism should exist as there's no other way to rebuild a library when you "repo put" some content to that library, I don't remember which - JS/CSS files or the clientlib configuration (updated js.txt, css.txt or .content.xml file) - updating some of those ones doesn't update the resulting client library file.
If you want to disable it on your environments' author for usual users, just set up the dispatcher access for the author instance and forbid it on the dispatcher. Allow direct access to that server (without dispatcher) only for developer IP addresses (we use VPN to achieve this).
Another way, for both remote and local AEMs, you can try to setup ACL in useradmin to disable the whole path /libs/granite/ui/content/dumplibs, but I am not sure it will help you
Also, you can try to write Sling Servlet Filter for that path (a service that implements javax.servlet.Filter, you can find samples in ACS Commons code or in WCM Core Components code), where you won't pass the processing to another filter in the chain or return another response.
