pam_systemd is the plug-in that makes the difference between the classic (pre-systemd) login process and the
Without it, the login process works as it did with SysVinit: if a user process daemonizes (i.e. closes its standard input, output & error streams, forks twice, then has the child process die leaving the grandchild an orphan, reparented to UID #1 by the kernel), there will be no way to track which session it belonged to. Instead of the entire login session and all its children being reliably encapsulated into a separate control group, all the processes go into the common pile. So the enforcement of per-session resource limits can't be done either.
Also, the user run-time directory
/run/user/<UID>/ won't get created, which might disable some features of some desktop environments, and things that attempt to be multi-session friendly like GnuPG Agent for example. And last but not least, the
user@<UID>.service system service and any per-user
systemd services managed by it will not be started: there will be no session D-Bus for this user/session, nor Pulseaudio. See
systemctl --user (in a system with a working per-user
At logout, without
pam_systemd being in play, the logout process won't be able to cleanly enforce that all the processes of the user session are definitely cleaned up at end of session (should the system administrator wish so; see
You'll also lose a simple way to plug in non-root actions to events like your user login/logout, or non-root actions conditional to things like filesystems being mounted or hotpluggable network/storage/bluetooth/other devices being present or appearing later during the login session.
If your goal is a lean, mean single-task machine, you might regard this as a successful amputation of a lot of unnecessary stuff; but depending on your goal, you might not.
Anyway, the question you referred to indicates the problem might be caused by something causing the system D-Bus to restart, which would require restarting
systemd-logind and possibly other system services that depend on the system D-Bus.
The root cause for your login slowness problem might also have been something like Pulseaudio being still configured to expect RasPi 4 hardware and being confused on not finding it.
systemd-based installation, there may be at least two relevant instances of D-Bus for each user session: a system D-Bus that enables selective passing of system-wide status information and control as configured by
polkit, and a session D-Bus for user-level things. Some GUI desktop environments may fire up a small extra D-Bus instance or two for handling accessibility and/or internationalization (input methods for Chinese/Japanese/Korean characters and similar).