At least, one wart that I’m aware of is that guix packages don’t install files into /etc and /usr directly.
What about files in /etc/pam.d? PAM will require files in /etc/pam.d.
What other warts do I need to be aware of?
Guix relies on profiles which are essentially stacked layers hiding libraries, binaries and support files lower down the stack. If you have your own installed things and/or configured things differently this might interfere with overriding. This also relies on conventions of the order of startup scripts which might differ between shells. This has be an area of frustration for me.
The process of grafting or modifying packages can also lead to confusion where a package might have grafted libraries where other packages use the exact same version with different grafts. From a GUIX POV they will live in a different folder in the /gnu/store folder and the configuration in the environment can get confused so the wrong dependency is loaded leading to confusing errors.
Most of these issues can be fixed by having clear areas of responsibility for the system managed packages and services, the home profile, your personal profile and any guix shell local folder profiles. With the aim to not have duplication over the boundaries.
e.g. nss-certs make certificates available. I would consider that a system wide reponsibility, so that is installed by the system config. It needs to be enabled by setting variables in the /etc/profile and the package deals with that. However on non-GUIXSD based systems this will be missing causing curl et al to fail, meaning on those systems it has to be added to the home-config, so the environment is updated while logging in. In theory this should work in a guix shell environment too, but that is hit or miss in my case as in general the zsh which I use does not load the profile script (wherever that is).
Another issue which might appear as a GUIX wart, but really is not, as it is the same on other distros, is getting all portals for flatpaks to work. It is easy to get in an inconsistent state which is hard to debug caused by the preceeding issue.
That sounds more complicated than gentoo’s portage which has its own warts which I have learned to overcome.