My global advice to customers on how to deal with untrusted, invasive proprietary software is always tosegregate them for install, and audit what results from install in a seperate template prior of merging those software into a template that is used for more trusted operations.
I like to seperate for example debian-10 from debian-10-proprietary, where proprietary would be an initial clone of debian-10 + proprietary related repositories.
I tend to agree with @Demi on randomly released .deb and .rpm that are not part of a repository and consequently doesn’t update itself: better to put that on a standalone qube, which is less then desirable approach, but at least undesirable outcome would only touch that qube, even more if only one qube relies on that template qube.
The general idea on this falls into the same category as deploying printer related software in a broadly used template: not a generally good idea because of the added attack surface. We all know that printers drivers are iffy, that additional services (systemd) are added at boot,etc. Whatever extends the attack surface needs to be carefully chosen and audited to be running by default on qubes on which that template depends, and should be a no go. It is better to fit a light-one-app-appVM where needed, depending on threat model and use cases, once again. I would personally not trust Zoom or any proprietary tools to stand side by side of carefully curated software installed on template shared with mission critical qubes i’m using.
I personally prefer to clone a known good template (debian-11) to a general persona-related template (debian-11-communication-proprietary), install software in the latter and then compare the filesystem to see exactly what happened there prior of taking a decision on if I keep that template distinct of others for one/two AppVMs. If no additional start-up services are installed, I might reconsider having it installed in a standalone qube, or sharing a template with other proprietary software. If that thing is not updated automatically, it definitely goes into a standalone, short-lived template-turned-into-standalone for hte time being I need that app where all my being is saying no, but others want me to use that app, so be it really ephemerally. Cloning on thin-lvm is no cost. Installing software there has space consumed for the diff of the installed software. As long as I do not intend to keep it there forever, its more like a install, use it delete it use-case.
Once again, I’m a big advocate of wyng-backups for that, which permits to just send the diff (–dedup is your friend) between debian-11 and debian-11-communication-proprietary to a local backup, including the qube that depends on it. If I do not use either the qube or the template, I make sure to have backuped the qubes.xml with accompanying https://github.com/tasket/wyng-backup/blob/master/misc/qubes-wyng-util tool, and if needed, I restore it a matter of minutes if I deleted it. No worries, small space consomption. Hallelujah.