No, systemd is not the root case of this issue but is a side effect of dependency choice dictate of virtual packages. Regarding udev, portage tree have 3 virtual packages:
virtual/udev (eudev, systemd, udev as providers).
Udev package has following libraries, libudev and libgudev (gudev part) and hence addtional virtual packages introduced:
virtual/libudev for packages linked against libudev (libudev can be provided either by eudev, systemd or udev, see above virtual/udev)
virtual/libgudev for package that linked against libgudev (same providers).
upower and upowr-pm-utils (drop-in replacement) now has virtual/libgudev dependency. Funtoo has no newer udev package, so virtual/libgudev dictates to choose systemd, eudev and other uncertain dependency graph. I find this behaviour as very misdesigned (or overly designed), which not helping Udev maintainence any better. I'm thinking about a permanent LONG-TERM fix for udev and Co. There was an initiative to use mdev as default but this is very conservative and better suited for servers, not desktops. Also, we would like to investigate possibility to switch to eudev, sa-called udev fork, which is freed from systemd churn, we had positive feedback from users, so it might be best option. The fix for this is ON HOLD as it one of the most critical packages in system.
P.S Funtoo has done good job in avoiding newer udev versions but number of problems accumulated dictates to have a permanent fix (if possible)