They didn't even try to solve it.
It took me less than 2mins of thinking (and I am hardly the smartest guy ever) about it to figure out that you can solve the potential privacy hazard that webRequest poses (extensions siphoning off request data) by introducing a special kind of content script, let's call it a request-script, that is input-only/one-way-communication except for a limited set of request manipulation and only when asked by the browser. Such as blocking requests. Of course, the devil is in the details here of what to allow and not allow.
The input-only nature still allows for it to be feed new/updates instructions, and it being a script it can still implement rules that cannot be implemented with a fixed rule list like google proposes. But it cannot make web requests and exfiltrate data like that, it cannot communicate back to the host extension and exfiltrate that like that, it cannot exfiltrate data, period. It only ever is allowed to perform certain (not all) request modifications and only when asked by the browser itself.
That leaves the "performance issues" google claims are a major problem. And indeed, there is a chance a misbehaving extension might obliterate performance. But you can do a lot of things in this space, too. "You" are the browser after all and any extension or any request script is at the mercy of what you're allowing it to do anyway. A low hanging fruit here would be to enforce that a request-script has to give an answer in a sane amount of time. Or warn users when an extension slows down requests too much.
And ultimately users will decide if a e.g. 100ms delay for each request is preferable over downloading a few megabytes of video ads for them or not. That is if google was really interested in protecting their users and improving their experience and did not have other motives...