There's some misconceptions being put forth in the article which I, as a developer of a Safari ad blocker, would like to address.
Content blockers are limited by design to ensure privacy and speed, but they may work together with other kinds of Safari extension. So, when AdGuard guys say that the only debugging tool you can use is Console, know that this isn’t true. There’s SFSafariExtensionHandler API which you can use with blockers as another extension with higher privileges to track who blocked what. Very handy in debugging (and informative for the user).
Should I say that converting something like EasyList to Safari content blocker json is trivial? It is. Granted, ABP has more capabilities in its extended syntax, so you won’t be able to convert everything. There's also some rules that don’t match 1 to 1, but it isn’t something that can’t be solved.
Compiling speed, for the process that happens once the blocker rules json is changed, is irrelevant for the users, unlike battery life. Thanks to the compilation, content blockers have less overhead.
The number of rules limit is a non-issue. As explained in the original, EasyList has lot of mergeable rules. I may add that it has some overlapping rules too. And if for whatever reason you hit 50k limit, you can add another content blocker extension to your app.
And the most important thing. It seems that AdGuard guys don’t get why content blockers in Safari don’t run scripts. It’s privacy. But Safari itself doesn’t prevent you from doing that, only not as a part of content blocker extension that is privacy-safe.
Speaking of YouTube ads, yeah, it’s a pain point. By blocking resources you can get to the point where an ad will be a white screen or a video loading delay. To get around those you have to get beyond what content blockers are offering. I’m thinking about adding that capability into my blocker, but it isn’t a priority.