1) As memory serves, no root required. If it doesn't in a legitimate situation ask for root access, don't use it.
2) It might be better to just make a new template, this way you cut away clutter and you're sure you don't introduce new issues. As an alternative, you can make CUPS active in your AppVM instead of your Template, by editing this file /rw/config/rc.local which even has an example inside it for CUPS, all you need to do is remove the three # marks. But keep in mind that this will introduce additional exploit/attack surfaces to your AppVM, since CUPS management will stay permanent between AppVM reboots. But in contrast it will allow you easier management to printer changes, which may be important if you make frequent printer adjustments or use it as a remote printer server which requires server changes on the CUPS server. If you just need to install a printer rarely, then it might be better to keep CUPS in the template, and put the driver/IP-address in the template, so that the AppVM can find it.
3) Try see if your printer has a Network or System feature that allows you to print out a print of your printers status and information. Many modern printers, and many of a few years old printers too, have this feature today. It might tell you various good things, like for example a name such as DNS name you can use, which stays the same even if the IP changes dynamically.
4) Are you on Qubes 4? That might be why it's a bit more tricky now, since the template has no network access to verify if it works or not, while Qubes 3.2. templates had network access.
Another work-around, which is by no means official approach, is to disable your networks internet access and isolate or remove any other systems on your network (so only your printer, computer and maybe your router without an internet cable in it, is networked), and then "temporarily" give your template network access in your VM settings. Once the printer works, you can remove the internet access to the template again, and re-apply your network again. Be mindful this isn't a perfect solution though, but it might be a last solution to consider if everything else fails.
As for another mention, some USB devices do not work in dom0 when it comes to qvm-usb and qvm-block {typically advanced devices like printers/yubi-keys, but not keyboards/mouse/some-usb-hdd's (semi because of design, and semi because of a bug. A bug which will likely not get fixed since we're trying to move away from dom0 USB uses in Qubes 4 on-wards. It causes issues on some hardware though, I'm in a similar boat to you here as I have to keep USB controller in dom0 to have a working system as too much other essential hardware is internally bound to the USB controller).
Also as far as I know, Qubes firewall only acts as a NAT, which means it blocks in-coming network, but not out-bound network. So if you initiate the connection to the printer, it should then allow a full connection for the printer to reach back to the AppVM. Last time I did a printer VM, I didn't need anything fancy here, it just worked by putting the printers IP (or its DNS network name address). So I don't think you need to mess with firewall networking, I'm almost sure you only need the address, which the printer should be able to print out for you in its settings menu.