Yes, currently only ad blockers it seems, though the author of the JS Blocker extension said he may consider using that API in the future (if the restrictions of the filter list size - currently 50000 entries AFAIK - are improved).

These 2 have their sources easily available:
Nope https://github.com/kaishin/Nope
Ka-Block https://github.com/dgraham/Ka-Block

Then I found few others
Wipr http://www.giorgiocalderolla.com/wipr.html
Adamant http://cocoaapp.com/adamant/
Roadblock http://www.obiedcorner.com/roadblock/
NoThirdParty http://nothirdparty.net/

Yes, something like that. However when this is an issue after updating via Sparkle as You hint the question is: why does that occur when Sparkle is supposed to take care of that? I briefly checked their source and it's really in there:
https://github.com/sparkle-project/Sparkle/blob/master/Sparkle/SUFileManager.m
and used from at least here:
https://github.com/sparkle-project/Sparkle/blob/master/Sparkle/SUBasicUpdateDriver.m
which should be there since at least Sparkle 1.12

I think the cause is simply the fact, that normally any file downloaded from internet source via browser is flagged as quarantined (it has the com.apple.quarantine extended attribute set) and once you have a zip archive flagged like this and unpack it, all of its contents will inherit it.

OS X won't let you launch an application with the quarantine flag (that's that Gatekeeper stuff) unless you deliberately allow it (Secondary click + Open, or via Security & Privacy settings: Allow apps downloaded from: Mac App Store and identified developers or Anywhere). Once it's successfully launched it will be then possible to launch it again without issues and that should apply to the Helper app as well, however I'm not sure how does the launchd exactly react to the quarantine flag because it isn't cleared even after the app is allowed to launch, only its data is modified a little (first 4 bytes which seem to represent some numeric value in the ASCII form and are "0001" (30303031 hex) after downloading and unpacking the app will change to "0041" (30303431 hex)).
It's entirely possible that even though that's enough to launch it manually, launchd will still reject it and it's necessary to delete that flag entirely in order to be able to allow it from launchd.

I don't use the Helper and have never tried it so I'm just speculating, but there may be basically 2 ways around it:

1. After downloading and unpacking the Cookie app, launch it at least once manually and allow it through the Gatekeeper if necessary
2. If the 1st method isn't enough, then you will have to clear the quarantine flag for the whole app, an example (for Terminal): xattr -d -r com.apple.quarantine /Applications/Cookie.app (of course you may do it right away with the downloaded archive (then the -r xattr argument isn't required) and only then unpack it)

Of course none of the above can be done other way than by the user themselves - otherwise it would be easily possible to circumvent the Gatekeeper protection...
I have no idea whether there's any more elegant solution besides finding some vulnerability in the Gatekeeper mechanism and making use of it (which would go against the whole idea of why it exists in first place and thus Apple should patch it)

Note that applications distributed via the Mac App Store shouldn't be affected, such apps aren't flagged with the quarantine attribute.

I tried it briefly when the beta was released and it did work for me.
There must be some specific condition(s) that cause Your issue.

Hello,
not sure if that would be appropriate for the Cookie app to be able to handle this, but please try to have a look at it if it would be feasible...

As You know, there's a new API for content blocking extensions since Safari 9.0.
Extensions that make use of that API don't seem to store their data in the usual browser local storage (which Your Cookie app can manage), but in the following locations instead:
Safari: ~/Library/WebKit/com.apple.Safari/ContentExtensions/
Safari TP: ~/Library/WebKit/com.apple.SafariTechnologyPreview/ContentExtensions/

AdGuard Browser Extension https://github.com/AdguardTeam/AdguardBrowserExtension/releases is one such example - it seems to generate and store its blockinglist into the above mentioned location and then uses that together with its settings which are stored in:
Safari: ~/Library/Preferences/com.apple.Safari.Extensions.plist
Safari TP:~/Library/Preferences/com.apple.SafariTechnologyPreview.Extensions.plist
e.g. storing nothing in the browser local storage at all.

It would be nice to be able to manage that stuff in Your app as well.

Some possibly interesting resources regarding the content blocking API:
https://webkit.org/blog/3476/content-blockers-first-look/
http://trac.webkit.org/browser/trunk/Source/WebCore/contentextensions
https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/BlockingContent/blockingcontent.html#//apple_ref/doc/uid/TP40009977-CH24-SW4
https://developer.apple.com/library/safari/documentation/Extensions/Conceptual/ContentBlockingRules/Introduction/Introduction.html#//apple_ref/doc/uid/TP40016265

Looks good to me, perhaps the time for release is approaching Let's see what more users will do with it.

The problem with the setting being out of sync should only affect beta upgraders, and not be a problem for new installs.

I'm not sure. As I mentioned - if I delete the Cookie app plist file (~/Library/Containers/com.sweetpproductions.Cookie5/Data/Library/Preferences/com.sweetpproductions.Cookie5.plist) and launch the Cookie app, the issue can be seen immediately. Doesn't this come close enough to the new install scenario? I know the app has some additional files on the filesystem, but aren't those independent on this?

Also, I'm not sure how is the "Display Favorites on Separate tabs" option supposed to work exactly. When I unselect it, I get only 2 tabs: Removal, Websites; while when selected there are: Removal, Cookies, Databases, Flash, Silverlight. As I understand it, it groups basically everything together, not just favorites, hence the "Display Favorites on Separate tabs" wording seems a little bit confusing and perhaps it should be changed to "Display Entries on Separate tabs" or so.
Perhaps the whole Favorites section in the General Preferences should be changed this way - as I understand it, it doesn't affect favorites only, but everything (at least I consider as favorites only those entries that are specifically checked as favorites)

Another one: when the "Display Favorites on Separate tabs" option is not selected, the tracking cookie counts (the 2nd number between parentheses - shown only if there are such cookies found) is shown in red color. But when that option is selected (so the display of all entries is grouped together) there's no red highlighting anymore - it's all in black.
EDIT: Now I somehow managed to get the opposite - when the display is grouped the number is highlighted in red, when all types of entries are displayed separately it's black. Then when I check (as favorite) some entry that contains tracking cookie, it changes from black to red (e.g. only those that are checked as favorites use red highlighting in the separate view).

EDIT2: Two more issues:

1. I had the feeling that when I launched the 5.0l beta for the 1st time, the actual display mode was "separate" but in the preferences window it did show the opposite ("Display Favorites on Separate tabs" unchecked). Thus to change the display mode I had to check that option first (which did nothing) and then uncheck it again. After that it did behave correctly - it reflected the selected option in preferences. I tried to reproduce this by deleting the cookie prefs (rm -f ~/Library/Containers/com.sweetpproductions.Cookie5/Data/Library/Preferences/com.sweetpproductions.Cookie5.plist) and was successful with reproducing it then. I compared the plist files for various scenarios and normally it seems that in the "separate" display mode the "TB Item Identifiers" and "availableTabs" properties list all 5 tabs to be displayed ("TB Item Identifiers" contains few more entries) and also "separateTabs" property is set to true.
   In "grouped" display mode the "TB Item Identifiers" and "availableTabs" properties list only those 2 tabs to be displayed and "separateTabs" property is absent.

After the very 1st launch (like with com.sweetpproductions.Cookie5.plist deleted) the "TB Item Identifiers" and "availableTabs" properties list all 5 tabs like in "separate" mode, but at the same time the "separateTabs" property is absent like in "grouped" mode.

To me it seems that managing the display mode via 3 properties ("TB Item Identifiers", "availableTabs", "separateTabs") is unnecessarily complicated (especially when first two of these properties contain almost the same data).

2. The "Removal" tab is the only one that's always shown regardless of whether the display mode is "separate" or "grouped". Thus when I'm at the "Removal" tab, open preferences and change the display mode, the view should stay at that "Removal" tab. Now the view switches elsewhere ("Cookies" or "Websites" depending on the selected mode) which is a little bit annoying. I understand that something like this is inevitable for other tabs, but with "Removal" this shouldn't happen.

One minor thing: With "Text Only" toolbar style used, there's no highlighting of the current tab. With "Icon and Text" & "Icon Only" the icon (of the current tab) would be highlighted in blue, but the text is always black. Is it possible to do something about it?

I've done some tests and it looks pretty good now, just some notes regarding user experience:

• As I've already written previously, some simplified view of of entries with just 1 cookie/database that would directly reveal that single entry might be useful.

• In the Databases tab, the ability to display various types of entries separately or actually select which ones to display (Browser Extension, Browser Extension Database, Local Storage, IndexedDB, ...) may be useful as well. For example I don't want browser extension related entries to show up there at all for most of the time. Now I can at least treat them as favorites so they can be easily skipped during removal, however they still show up in the list which is unnecessary. The ability to select what exactly I want to show up there would be better.

• There's some inconsistency in behavior of the Remove option in Cookies and Databases tabs.

1. Cookies: check website entry (as favorite) so it's both checked and selected at the same time, press Remove (at the bottom), the entry grays out (which seems like the data was actually removed) but it still shows up there and is still checked, then after unchecking it disappears.
2. Databases: check website entry (as favorite) so it's both checked and selected at the same time, press Remove and nothing happens.

The question is whether the Remove option should remove the entry that's both selected and checked (as favorite) at the same time. In any case, the behavior should be identical everywhere.