People put etc in git even: https://joeyh.name/code/etckeeper/
The registry is much more magical and it is difficult to find and remove cruft, so I suppose there's an argument against it.
Imagine the use case in reality. You accidentally rm -rf your /etc folder but you still have the git tree. /etc itself is gone, entirely. Most of your tools will seize working almost immediately, the only chances you have are having a terminal already open to a root shell. Your Virtual TTYs on other screens won't work (login uses /etc/passwd, which is gone) as well as any sudo command.
Recovery from the life system is likely impossible unless you have a root shell open and git doesn't refuse to work (it might since it checks for /etc/gitconfig, if you made any critical settings here, git stops working). Live recovery also has other issue; some apps might still be writing to or reading from /etc. They might have an open handle. Recovery will result in some processes of the same binary running with different configurations. That will be a joy to discover once it inevitably starts to corrupt the system stability.
So your only way of meaningful recovery is a live system on a USB stick. Do you have one ready to use right now? Like, not prepared in a shelf somewhere but right now is there a live linux system within your reach? If not, it's rather likely it will take a while to find it.
Once you've done that, you can bootup your computer, unlock any encrypted disks you use and install git into the live system. Then you hopefully remember how to recover a git repo using it's tree only, if not, hopefully the live disk's network works.
If recovery succeeds over git, you can reboot and pray the last checkpoint in git isn't too old. Have you changed the LUKS keys in the meantime and did you forget to checkin crypttab? Or did you change your Xorg Conf because X stopped working?
The short answer is; it might be easier and just as complex to simply reinstall the system while backing up your home folder.
Hmm, I've never done this. In terms of config files, are there never any breaking changes between versions? Like ..is a v1.0 config file always guaranteed to work with v2.0 and vice versa? I guess and a related question - what is the best way to determine if an /etc/ config file isn't required?
It gets more exciting the further you drift - e.g. if you're going to Debian buster, or something more significantly different like Fedora/RH, you'd probably want to cherrypick config changes from /etc, though /home should be fine(tm).
you start culling packages with apt purge, that should remove config files too, and see what breaks, if nothing, well, try to push your luck further.
also with dpkg -S /etc/some/file you can see which file belongs to which package and target that package
usually on a server you know what you don't need. it's a bit more trial and error on a desktop. (because those can break in a lot more fun, unexpected ways, harder to know what is needed)