First of all thanks to carstene1ns for opening a discussion on this issue. I've tried to do the same thing yesterday  but no discussions resulted in the aur-requests ML. I wonder if anyone ever read aur-requests.
(1)inhibition threshold - It is much easier to remove a package now. (2)response time - Requests get accepted before the package maintainer or others have time to explain or react.
Now you might ask me to provide some evidence... Let's blame two users today: FredBezies and foutrelis.
-1 Let's avoid to "file bugs" for people that tries to help your community. Surely, there's a way to make things better, so come here and with your work show us how to do that better :)
foutrelis seem to like clean lists, as he just accepted any deletion request that was open today (including the absurd ones by FredBezies), without reading the mailing list before and without providing a reason. If it does not really make sense to answer questions and remarks like Scimmia and I (and others!) did, the aur-requests mailing list should be read-only.
I had a similar issue with a different TU (Xyne)  which merged a good working package  inside a broken unmaintained package  (moreover I think that packages owned by a TU should be ALWAYS discussed with the TU, maybe there's a better reason for a package exists) but I believe that he missed the previously message  written on the aur-requests ML.
What can we do to make things better? Should we (re)write the policy for TUs about accepting AUR requests? They should at least investigate. I think a good start would be to have users provide real reasons for deleting a package and trying to fix them otherwise (themselves or with help from the maintainer).
We could also find a way to avoid that TUs involuntarily tell people conflicting things. If a TU awaits a reply from a maintainer, another TU shouldn't be able to close or reject the same request or maybe he must know what he's doing.
At the actual state the only usable channel is the aur-requests ML and it would offer a good way for interactions, archives included, opened also to discussions for packages maintainers or casual people that could be interested in the requests. However no-one seems to be interested in such ML, maybe for the too high number of notifications that "spams" the ML.
 https://mailman.archlinux.org/pipermail/aur-requests/2014-August/001070.html  https://aur.archlinux.org/packages/gt/gtkparasite-gtk3-git/PKGBUILD  https://aur.archlinux.org/packages/gtkparasite-git/  https://mailman.archlinux.org/pipermail/aur-requests/2014-August/001022.html