Because it’s generally discouraged to do stuff in the template except for installing applications. A general good practice I’d say. And also, templates don’t have internet generally speaking. So it’s more convenient to do on an app qube.
Since you’re compiling something anything malicious in the compilation chain could result in a malicious artifact at the end, so I don’t think it would matter in this specific case. So you’re basically trusting that nothing is malicious if you install on the template. Regardless of whether or not you compile it in the template.
Just run the script and at the end it will tell you where the produced .deb is. Not all do this.
That or sudo apt install file.deb generally works as well and it even installs dependencies.
This is probably already better answered elsewhere if you look for “flatpaks vs. distro packaging”, so I’ll stick with the Qubes-specific stuff.
When you install flatpaks in Qubes through Qube Apps, it installs them on the app qube, not the template. This is excellent if you only really need that application in one qube. Even if it has malware and compromizes that qube your template is unharmed. However, the downside is that you need to update that application manually since automatic updates (through the Qubes updater) only update repository (non-flatpaks) installed on templates.
So besides the usual disadvantages of flatpaks (large size, often unofficial builds, system integration issues) you have a few use cases that actually justify its use despite the inconveniences.
But in the end I think installing stuff on Linux is a mess and on Qubes even more. So I actually advocated in the past for an easier way of installing flatpaks on Qubes