The path to the answer is already provided in the QSB:
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1]
[...]
References
===========
[1] https://www.qubes-os.org/doc/testing/
However, the larger issue here is that the testing repos are for testers. When you enable any testing repo, you need to understand what you’re getting yourself into, including the risks and responsibilities you’re assuming.
Many regular users, especially non-technical folks, just want things to work and get upset and frustrated when they don’t. That is exactly the kind of user who should not be enabling any testing repos. The people who should be enabling testing repos are those who have the right expectations and mentality, are prepared to encounter problems, have the wherewithal to deal with them, and – most importantly – are willing to report the results of their testing to the Qubes developers in the correct way so that things can be fixed and improved. Remember, the whole point of testing any software is to find and fix bugs and improve things!
Over time, many of us have forgotten this and now see security-testing as merely a way to get security updates faster. The old QSB text, which provided the exact command required to get all updates immediately via security-testing, fed this misconception. People began to see each QSB as giving them a job saying, “In order to handle this QSB, enter this command in dom0.” But, when you pause to think about that, it makes no sense. If we truly wanted everyone to do this, there would be no need to tell everyone to manually enter a special command. We would just scrap security-testing and push all security updates immediately to the current branch so that updating normally would pick them up immediately.
In fact, we used to do this, but it turns out that, as with any software update, there can be bugs! And it turns out having testers test the updates before they go out to the entire userbase is a good way to catch and fix these bugs before they cause avoidable problems for everyone. Hence, security-testing was born. It exists for a reason!
Some of this was also discussed in QSB-068: Disconnecting a video output can cause XScreenSaver to crash.
No one ever said not to use the CLI for that. I think you’re misremembering the recommendation to “use Salt for updates” as “never use the CLI” or something. As the Updating Qubes OS page clearly states, “installing packages using direct package manager commands is fine,” and templates are installed as packages in dom0.