Am I wrong?
Your analysis is correct, but i think there is nuance here.
Is there any sense in performing the check more frequently than once a day?
The frequency of the check determines the granularity of the change detection. More frequent == detect changes faster, but what time is of the essence for you? In my own work daily is normal, but less often is used when the system has a lot of disk to scan.
Does AIDE only protect my system from attackers that do not have the right amount of permissions on the system?
This is the important question.
First of all, recognize that this is only a detective control. It doesn't fix anything, it only alerts you that something is off. The "protection" it supplies is subject to false positive and false negative -- either it alerts about a change you don't care about (which is a tuning issue and can be addressed in other ways) or it doesn't alert you about a change you care about, usually because it can't see it [because the tool has been altered or the database has been altered] or because the change was designed to not be visible to the tool (e.g. they cleverly designed a change with the same size and hash). I'm going to ignore that last possibility in what follows, since that's usually a tuning issue as well.
Back to the question. What AIDE can do is scan a system for changes. I think many people use it with the DB and scanning engine on the host itself, and this allows for identification of changes without a lot of effort. This is helpful in the case that the change agent isn't aware of or doesn't have the permissions to change the AIDE binary and database. That's a pretty common case, actually, and its really helpful in the 99% of cases where you don't have an APT with nation state resources. Mail out a report of the changes, and maybe even reset the database so you don't report the changes twice. Life is pretty good.
As you point out, if a malicious change agent has access to the AIDE binary and/or the database and/or the libraries that open files from disk (i.e. AIDE opens the file, and the library says "no changes, no sir!" no matter what the disk looks like) you are also out of luck. There are some things you can do in that kind of APT scenario. Lots of people have the database on write-once media stored offline, for example, and only mount the AIDE binaries, DB, and such during a maintenance window. An even better approach: clone the actual disk via a mechanism that isn't visible to the OS, and boot a system from a separate gold copy host where the AIDE binary, DB, and disk access libraries are stored; mount the disk, and then run the report on that cloned copy. I suspect there are probably still scenarios that can cause false negatives, but I don't see one offhand.
It all depends on how much work you are willing to do, given that its just a detective control. Who is your adversary? How much money you got? What's the impact of a compromise in integrity? Are there any other approaches?
AIDE is an incredibly useful tool. I've written other tooling around it. But its not perfection.