The Qubes backup system has a security feature that most other backup options lack: authenticated encryption. When you need to restore from a backup, you may think the file you’re restoring from is your backup file, but what if it’s not? What if an attacker has replaced it or maliciously modified it in some way to attack your system? The Qubes backup system is designed to protect against this, allowing you to safely restore from backups in dom0 even when if your backup file has been “in enemy hands.” I’ve described this a few other times on the forum, e.g.:
One of the main advantages of the Qubes backup system is that the backups it creates are not only encrypted but authenticated (and thereby also integrity-protected). Most other backup methods, including DIY procedures, do not feature this property or do not implement it correctly. (For example, if you’re not sure whether you should encrypt-then-MAC or MAC-then-encrypt, or if you don’t see the difference, then you should not be taking a DIY approach to this if security matters.) Authenticated bac…
Well, as I mentioned above, asymmetric encryption is notably weaker than symmetric encryption in certain respects, so you certainly wouldn’t want to use asymmetric as the default in an encrypted backup system. Maybe some individual users are willing to sacrifice some security for some convenience this way, but it shouldn’t be the default. On the other hand, it’s also possible to use PGP for symmetric encryption, which might be what you’re referring to. I vaguely recall that this possibility wa…

So, could one just back up AppVMs frequently, and templates perhaps infrequently but then again, perhaps not at all? (If your template creation is scripted or salted, then in theory you need never back them up, BUT you will want to back up your scripts and/or salt recipes, and you will want to do so THOROUGHLY (offsite backups, the works.)
Yeah, basically you should back up everything that would be impossible, too difficult, too costly, too cumbersome, too time-consuming, etc. to recover or replace, and not worry as much about backing things up that are easy and cheap to recover or replace. So, if your templates can be completely recreated from some notes that you have backed up, then perhaps the only reason to back up the templates themselves would be convenience and time savings (i.e., being able to restore from the backup instead of having to go through the recreation steps), or for the sake of redundancy (e.g., in case your notes turn out to be wrong or missing something). For most users, it probably isn’t a big deal if they forget to write down that they installed a certain app, since the next time they needed it, that need would remind them of it, and they would install it at that time. In such cases, the stakes are relatively low, so there is not a great need to be fastidious about it. The higher the stakes are for you, the more effort you should devote to this stuff. If you can’t afford more than N hours of downtime, for example, then by all means, back it all up.