How is allowing login for a sudo group member safer than allowing root login?

sudo improves safety/security by providing accountability, and privilege separation.

Imagine a system that has more than one person performing administrative tasks. If a root login account is enabled, the system will have no record/log of which person performed a particular action. This is because the logs will only show root was responsible, and now we may not know exactly who root was at that time.

OTOH, if all persons must login as a regular user, and then sudo for privilege elevation, the system will have a record of which user account performed an action. In addition, privileges for that particular user account may be managed and allocated in the sudoers file.

To answer your question now, a hacker that compromises one user account will get only those privileges assigned to that account. Further, the system logs will (hopefully) have a record showing which user account was compromised. OTOH, if it's a simple, single-user system where the privileges in the sudoers file are set to ALL (e.g. %sudo ALL=(ALL:ALL) ALL), then the advantages of accountability, and privilege separation are effectively neutered.

Finally, in regard to the advantages of sudo, the likelihood is that a knowledgeable hacker may also be able to cover his tracks by erasing log files, etc; sudo is most certainly not a panacea. At the end of the day, I feel that like many other safeguards we put in place, sudo helps keep honest people honest - it's less effective at keeping dishonest people at bay.

If you use ssh with a key to login, then the password is a 2nd factor. There is also a small amount of protection in not using a default user name. (As noted by others, this protection is that it reduces load on you machine (not having to check so many passwords/keys), and allows blocking.)

The other main safety effect, is that you make it harder to accidentally run something as root. So not a defence against malicious damage.

sudo helps improve security in a couple of ways:

• It allows for fine-grained permissions. Among other things, with sudo you can:
  • Prevent a user from trivially accessing an administrative shell (which makes almost any attack you can name much more complicated).
  • Limit which commands a user can run.
  • Limit what commands can be invoked based on various properties of the login session itself (for example, allowing only a very restricted set of commands for SSH logins, but allowing full access for physical console logins).
• It provides a paper trail that makes it easier to figure out who did what when. This is very important for postmortem analysis after a system is compromised, because it gives you better information about how the system was compromised. Note that this is in addition to any shell histories and any other logging.
• Use of sudo instead of a root account or well-known admin account name discourages casual attackers. If you pay attention to the authentication logs on any system that has SSH on port 22 exposed to the internet, you will notice that almost all attacks are generic, attempting to brute-force a handful of very specific usernames (root, admin, toor, pi, and similar ‘well-known’ names that are widely used for administrator accounts). By not using such accounts at all and instead relying on privilege elevation using sudo once you are already logged in as a regular user, you completely eliminate a large chunk of attack surface.
• In certain configurations (targetpw mode (which you shouldn’t use on multi-user systems, but is a reasonable choice for single-user systems), or when using something other than a password for the initial login (such as an SSH key)), using sudo provides a second layer of authentication that an attacker must get through to get root access.
• It provides a clear demarcation of the permissions boundary. IOW, it makes it harder to accidentally run something with more privileges than it needs, because you have to consciously choose to do so. This, in turn, helps provide a marginal additional layer of protection against social engineering attacks.

Overall, none of this is all that major in terms of preventing external attacks (although the first two points are huge for protecting against internal bad actors), but all of it is also stuff that has a very low impact on usability, so it’s generally worth it to just do it to provide the marginal improvement to security it gives.