Understandable. I'm not here to persuade you otherwise but for others reading this, I'd like to add some context.
Security/trustworthiness: Having a package in the OpenWrt repository nominally means that the code was reviewed, which is an advantage from the security/trust point of view. Although in practice (to my knowledge, please correct me if I'm wrong) only at initial package submission there is any sort of actual code review, and at subsequent updates (which eventually come to dominate the code base) this becomes a matter of trust between the users and the developer/maintainer because actual code updates are not regularly reviewed by anybody besides them. So as a matter of fact, availability of an official package mostly means that someone with commit rights for the official packages repository deemed the developer trustworthy enough at the time of the initial package submission. So this boils down to developer reputation in the community. Arguably maintaining multiple long-running independent open-source projects with thousands of users and an active forum thread, and contributing to other established projects, including to OpenWrt itself, may be deemed equivalent.
Compatibility: a package in the repo is versioned and each version is typically tested and officially compatible with exactly one OpenWrt release. This means that the developer doesn't need to test the package against every possible OpenWrt version, so it's easier to maintain the code base and utilize new features. On the flip side, this also means that the user has to either continually update their system every time a new OpenWrt release drops, or stay behind with older package versions which may be or become buggy, which is especially relevant to projects which depend on external resources (such as 'feeds' for an adblocker). From this standpoint, running a project which is not in the repo has the advantage of making regular application updates available to users who do not want or can not upgrade their OpenWrt version regularly. This does put somewhat of a strain and a responsibility on the developer to test against multiple OpenWrt versions. adblock-lean, for this matter, works fine with every OpenWrt version starting from 23.05 and up, including the current 25.10. We achieve this by making the code flexible and minimizing assumptions about the built-in OpenWrt facilities.
It is essentially that but I think our distribution method is not as bad as simply downloading code from some link and then just using that. In a nutshell, the installer which the user manually downloads then uses the Github API to fetch the actual distribution archive (which includes code snapshot + installer snapshot), and then calls the installer from the archive. That second installer then actually installs the application. It's not completely impossible to get corrupted code this way, but very unlikely considering that the code is distributed in a .tar.gz archive and typically when such archive is corrupted, corruption will trigger an error during the extraction, which we check for and handle.
adblock-lean does not self-update completely automatically. It's up to the user to issue the command service adblock-lean update at the time when they want to update.
Anyway, I don't have an expectation that you (or anybody else) recommend adblock-lean. I was genuinely curious about your reasoning. We're obviously not making any money with this project, but we did invest a lot of time in development, so the only reward is knowing that people are using the project and enjoying it. Having someone make a recommendation which specifically omits it does hurt a bit, but your reasoning is understandable.
For people reading this, I also want to mention a few other advantages of adblock-lean which IMO matter. adblock-lean's code base consists (by my very rough estimate) of about 50%-60% error checking and reporting code, and then the rest is functionality implementation. Just the main error reporting function reg_failure is called 198 times (in my local development version). So while we are intentionally limiting the feature set to what we think is essential for an adblocker, the code base is very robust, so the users have to deal with very few bugs and we (the maintainers) have to deal with very few support requests. Also adblock-lean gives the users complete runtime feedback in a human-readable and friendly way, so the user doesn't need to guess whether it's working properly or not, as every important thing is printed. adblock-lean was designed to be very user-friendly despite having no luci interface (at least for now). Everything that can be automated is automated, including the setup procedure which supports simple setups and complex setups with multiple dnsmasq instances alike. So getting adblock-lean going is literally a matter of seconds from installer download to having functioning network-wide adblocking tuned for the specific system, and the user needs absolutely no domain knowledge or expertise. And finally, adblock-lean was designed to be as efficient as possible in respect of memory use, while being as fast as possible. So it is truly consuming significantly less memory than other solutions during the processing stage, which essentially means making larger lists available to systems with less RAM.
, because used on 32MB RAM openwrt device.