From the discussion on IRC, I suspect we are seeing the audit messages now because they only get generated when access is denied to existing files: not when the process tries to access a path that would be denied if it existed.
Since we add /var/lib/snapd/desktop to $XDG_DATA_DIRS and that setting leaks to the sandbox, it is not surprising that various libraries will try to access paths under that directory. If I created a /var/lib/snapd/desktop/themes directory, I wouldn’t be surprised if I started seeing denial audit messages about that too.
So I propose that we silence denial messages for accesses to /var/lib/snapd/desktop/**, since they are likely to just be noise.
As for the browser-support and desktop-legacy interfaces granting access to /var/lib/snapd/desktop/applications directory, I suspect that this could safely be removed. Neither interface lets sandboxed applications do anything useful with files in that directory (since they don’t allow launching of other snap applications). I kind of wonder if the rule originated in browser-support from seeing the audit messages, without deciding whether the access actually made sense?