$distroalready existed
This is one of the main reasons why I never use the original templates that get installed by Qubes OS, but always clone them. Another good reason would be to always being able to start from a clean, unmodified baseline by making a clone of the Qubes OS provided template.
settings in dom0
It makes sense to restore them the way they are… so you are able to pick and choose what to restore. Otherwise, if you messed something up in dom0 your only options would be to restore the mistake or start from scratch.
launchers and the panel setup for xfce4
At login screen user Ctrl+Alt+F2 to go to a text terminal. Login. Nuke or rename the ~/.config directory and then move the restored .config folder into your ~/ home. Logout. Ctrl+Alt+F1 and login with XFCE. 
I also backup my sys-firewall customizations to a
/home/userfolder in an AppVM so I can more easily restore these into a freshly installed sys-firewall. I’d be intersted, how @Sven would solve this when you can’t create sys-firewall from dom0 because the custom dom0 can not be created without sys-firewall.
I am not entirely sure what you are asking. In my case modifications to sys-firewall are either in the respective template (e.g. apt-cacher-ng package) or they are documented in a bash script in dom0 I can use to recreate my sys-firewall from scratch (along with all other system qubes).
After 5 years of Qubes OS usage this would be one of my main recommendations: document all of your modifications regardless of how “unimportant” they are. Either write them down in a notebook/text file or better automate them in a bash script or salt recipe if you can.
Following this one guideline takes most of the sting out of restoring/upgrading/switching template distros.
$distro template is now a different version than the current 4.1
$distrotemplate
That is a good thing, see above.
so I ended up maintaining two major versions of templates for the same distro.
Don’t use or modify the Qubes OS provided template. You can even remove it after cloning if you are tight on space. The key here is to always be able to go back to a clean version and your template name not being in the way when installing/restoring the Qubes OS provided version of the template.
standalone VMs, as these are easier to restore?
And then you have to update/maintain each qube separately? With it’s root partition keeping state and loosing a major advantage of Qubes OS architecture?
Standalone VMs are useful for specific use cases, but by no means should they be your default option.