Gabriele, indicated we shouldn't use the current methodology unless they have very good alternatives - but the same applies to stopping it.
We don't have the capacity to handle a big bulk increase in pending changes as proposed by gbfv on en-wiki and presumably others as well - and making very short-length blocks on proxies would require a major increase in Steward time, which a quick review of the average myriad steward backlogs indicates is not really a resource in sufficient supply to be profligate with.
Others have proposed using a professional group of employees to either replace or outweigh the CU corps. I seriously doubt many projects are going to be happy with vastly increasing the amount of blocks implemented by the foundation on the basis of evidence that very few can see.
Vermont has correctly summarised the issues that come with any auto-implementation of IPBE.
But there clearly is a need to act on the growing set of problems, and DannyH's list has many good options (and even the not so good options are the ones that obviously should be considered to judge the tradeoff threshold).
If we can smooth the process for Stewards (on their side) to shrink the time needed for each action, that's the same effect as having more active stewards. That let's us consider options that currently may be a non-starter. We also need to smooth the process for requesting unblocks (or even understanding the problem). No doubt this is excabated by the "they can't hear you" https://en.wikipedia.org/wiki/Wikipedia:Mobile_communication_bugs problems.
We absolutely need a process for simplifying and clarifying both understanding IPBE (global/local) and then requesting it.
Now, I suspect most "innocent" proxies being added/blocked would probably become "harmful" if unblocked (that is, sooner or later they'd be used problematically), but that's definitely something that should be tested as we expand on blocking proxies just because we know they're proxies.