Yeah, it’s disappointing that content blockers and Safari extensions are not configurable per-app, in the same way as photos access or whatever else. This seems like an obvious feature, so hopefully the reason for its delay is complexity of implementation; IIRC app developers have basically full access to WebKit in a WebView, so enforcing the use of content blockers would be difficult. But Apple could make implementing content blockers for generic web views a requirement that they check for during review. I say “generic” because there are likely some use cases where the WebView isn’t being used as a general purpose web browser, like it would be in Apollo or Feedly. So it might be infeasible as a hard requirement.
On the other hand, Apple wants to incentivize developers to build apps, and they have a history of gatekeeping features from the browser to force certain use cases into the App Store. So hopefully they’re not omitting this setting to encourage app developers to create apps where they can run their “safe ads” without content blockers.
On Android, they solved this with "Custom Tabs", which is an API that opens a nicely integrated webview with extra buttons added by the app (like a tweet button) but internally is the default browser. Almost all apps use this now. I have this with enabled with Firefox
