You are conflating a "present/absent" question of this permission with Google's stated intent. The key modifier here is broad "read/modify data" permission. If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions.
Furthmore the webRequest API has been nerfed to the point that it cannot block requests any more, only track them. The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.
> If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions.
Do you have a source for this? Have other ad blocking extensions been removed from the store? I find it very hard to believe that Google would block uBlock over something so clearly and obviously required for its functioning when they've said over and over again that making sure ad blocking extensions continue to work is a high priority for them.
> The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.
Well, the stats from the commit in question clearly disagree with you—of 22,245 rules, only 145 use unsupported regexes. How is DNR "not flexible" enough here?
I can't provide a source for Google axing a too-invasive extension, because they've never been straightforward about it. My favorite excuse was that the extension's description was "too detailed."
DNR does not allow uBO's _Block media elements larger than [x] KB_[1].
DNR does not allow to know which network request was blocked by what rule. To do so requires the `declarativeNetRequestFeedback` permission, which is available only on locally unpacked extensions, for debugging purpose. This prevents porting to MV3 uBO's overview panel[2], including the "advanced user" version to set firewall-like rules[3], and uBO's logger[4].
Furthermore, the filter-matching algorithm of DNR does not match the filter-matching algorithm of uBO regarding redirection. In uBO, redirect filters do not compete with block filters, they are looked-up after a network request has been blocked. With DNR, redirect rules competes with block rules, such that uBO's `redirect-rule=` filters can't be ported.
Furthmore the webRequest API has been nerfed to the point that it cannot block requests any more, only track them. The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.