To see the exact difference, you can review the Groups Administration / Access Rights and Administration / Settings from the menu sequence:

Settings -> Users - Groups

Look at the Access Rights tab to see the models/objects that each group is allowed to read, write, create and delete.

But mainly, the Access Rights Group allows members of the group to manage the permissions of other user accounts and the Settings Group allows members of the group to manage all of the configuration options of the system.

The reasoning is the difference between HR and IT admin, both have/need the ability to create the other type of user but they do not actually want the access. If you are interested in restricting the users, you would create a group with the appropreate permissions. Or just set the user permissions every time.

As Mustafa Rawi has pointed out, a member of 'Access Rights' can actually create a new user with the 'Settings' permissions or add himself to the 'Settings' group by activating 'Technical Features' for their account - after activating 'Technical Features' they have access to the 'Groups' navigation point. Funnily enough, if they're in the 'Access Rights' groups, they can't simply edit their own user through the normal Edit User Form and select 'Settings' from the 'Administration' drop down. So the workaround of activating 'Technical Features' has to be used.

I don't get why there is a distinction between the two groups. Maybe this has historical reasons. From a security point of view, treat users from the group 'Access Rights' as having the extended 'Settings' permissions. They're basically super users.

Edit: Actually, it looks like if a user is in any group that has full CRUD permissions for res.users, they can create a new user with elevated group permissions ('Technical Features', 'Settings).

Does anybody have a solution to forbid a member of 'Access Rights' add 'Settings' group to himself ? This would be helpful to let a user manage access rights but not let him install apps or modify views...