It is the combination of browser-support with daemon as the root user (which is what is done by default for snaps) that is the issue - essentially this combination allows a snap to take ownership of a device - which is why we then require vetting of the publisher etc. However, even if a snap drops permission to the snap_daemon user there is nothing stopping the publisher from removing such functionality in the future, hence why even if the snap_daemon user is used we still do the publisher vetting.
In general though, if the privileges can either be reduced by having the daemon within the snap run as the snap_daemon user - or by splitting these between two different processes within the snap - one that runs as root but does not have browser-support and one that runs as snap_daemon with browser-support - then that seems reasonable and the security review seems tractable in either case (this is still better than having the whole thing run as root with browser-support).