The portals for native-messaging grant the browser the ability to access the system wide keepassxc.proxy via e.g the Firefox snap, but the browser still needs to actually know that KeepassXC is available to use, which is what writing these manifests are for.
The portals don’t assist with creating those manifests in the first place. The status quo would be most apps don’t implement this functionality and it probably doesn’t come up much. Ones that do might have a strong bias to not be sandboxed and so it feels like stuff “just works” but there’s a very specific step the apps are taking to inform the browsers they exist.
Specifically then, the FF snap is actually looking at $SNAP_REAL_HOME/.mozilla rather than its own snap $HOME because that’s where every non-sandboxed app would place them, so on with the rest. Ideally the portals would provide an alternate way to advertise native-messaging support themselves, but from what I’m aware that’s not the state they’re currently in.
Also, whilst KeepassXC is sandboxed, the actual browsers may not use the portals at all, so for e.g Google Chrome from Google’s own Apt repos, it accesses KeepassXC’s snap without portals, which needs the files in these places again. From the proxy’s perspective, it doesn’t care if you’re sandboxed or not, it’s just writing to STDIN and STDOUT.
So providing this interfaces also fixes classically packaged browsers who don’t have portals, as well as OS’ which don’t have James’ (currently) downstream patch. I’d expect the Firefox RPM package in Fedora to work with the KeepassXC snap with this change for example.