What are the potential vulnerabilities of allowing non-root users to run apt-get?

apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

From GTFOBins

This gives you a root shell on the system. No creating packages and adding fake repos; this will give the user who runs this command easy and simple access to root.

So, in answer to your question, you are effectively giving root to every user who has access to this binary. If you are willing to do this, then you might as well just give them sudo access or the root password.

You say you're using a "custom curated apt repository" but there's no way to enforce that. Any user that can invoke apt can specify their own source list, for example apt install root-backdoor -o Dir::Etc::Sourcelist=~/apt/my-own-sources.list. This can be done for all the other config settings as well, which means you can also have apt overwrite arbitrary files with content you choose (e.g. by setting the cache directory for retrieved packages).

Packages can (and often do) execute arbitrary commands during installation. Since the attacker can control the sourcelist, they can create malicious packages that either give unprivileged users a privileged backdoor, or simply execute (as root) any command the attacker desires as part of the "install" process.

apt is absolutely not a safe program to let people run (with root privileges) if you want to prevent them from running arbitrary code with root privileges.

EDIT: I want to call attention to this answer as a much cleaner way to get arbitrary execution (as root) out of apt.

Would preventing users from specifying their own sourcelists (e.g. by making a wrapper that specifically calls apt-get install -- <packages> with root privileges) be sufficient to prevent users from installing arbitrary packages (and thus prevent arbitrary code execution as root)?

Nope, apt-get can also pick up packages from paths. An attacker could create a malicious .deb package that patches /etc/<something> for root access upon installation via e.g. apt-get install -- /path/to/foo.deb.

You might be able to make it work securely if your custom wrapper script only accepts what's on a whitelist of package names, and if you can guarantee the packages are only picked up from your sources list - and can never be supplied via custom configs, environment variables, etc.