While starting to make use of the new cups printing interface in web browsers, replacing cups-control by cups there, as recommended here, it turned out that the CUPS Snap in proxy mode did not clone the print queues, at least if there are no network IPP printers around (observed by @osomon and @nteodosio, thanks). This was caused by bugs in the CUPS Snap itself (cups-proxyd did not do an update right after starting (fixed), CUPS Snap needs to plug cups-control to use D-Bus services of host system’s CUPS (fixed)) and a bug in snapd (erroneous restriction peer=(name=org.freedesktop.DBus,label=...) for CUPS D-Bus access, Pull request #11843 on snapd).
As soon as the fix for snapd is merged (snapd 2.56) the CUPS Snap as proxy for the cups interface will clone the system’s print queues correctly in all cases.
For now, at least when starting the CUPS Snap the cloned queues are updated, as well as on appearing or disapperaing of a network printer. So if a new print queue does not get cloned (not appear in print dialogs of snapped applications), either power-cycle an arbitrary printer in your local network or restart the CUPS Snap (sudo snap stop cups; sudo snap start cups).
Thanks, @jamesh for the pull request on snapd, and @mvo for approving this pull request.