This isn't peculiar to Raspbian or even GNU/Linux; evidently it's used on OSX too, although perhaps not the same way. Both operating systems are a form of unix -- I found that OSX question by quickly searching "unix staff group". OSX actually aims for (and receives) certification from SUS and POSIX; the use of staff there may be to comply with the former.

Linux distros are not so certified, however. There's no staff by default on Fedora, so it is probably just the Debian side of the family. The explanation of purpose from their wiki is:

staff: Allows users to add local modifications to the system (/usr/local) without needing root privileges (note that executables in /usr/local/bin are in the PATH variable of any user, and they may "override" the executables in /bin and /usr/bin with the same name). Compare with group "adm", which is more related to monitoring/security.

Which also explains why /usr/local is set that way.

note that the set user or group ID on execution (s) bit is set

I'd presume this is to allow executables there to write data even when run by someone who isn't in the group; it is safer than having them owned root and setuid.

This isn't peculiar to Raspbian or even GNU/Linux; evidently it's used on OSX too, although perhaps not the same way. Both operating systems are a form of unix -- I found that OSX question by quickly searching "unix staff group". OSX actually aims for (and receives) certification from SUS and POSIX; the use of staff there may be to comply with the former.

Linux distros are not so certified, however. There's no staff by default on Fedora, so it is probably just the Debian side of the family. The explanation of purpose from their wiki is:

staff: Allows users to add local modifications to the system (/usr/local) without needing root privileges (note that executables in /usr/local/bin are in the PATH variable of any user, and they may "override" the executables in /bin and /usr/bin with the same name). Compare with group "adm", which is more related to monitoring/security.

Which also explains why /usr/local is set that way.

note that the set user or group ID on execution (s) bit is set

This means that files created in that directory will inherit that gid:

GNU Coreutils: Directories and the Set-User-ID and Set-Group-ID Bits

The only difference this makes with a normal umask of 022 (meaning by default, files are created with group write permission masked out) is that it means subdirectories created there (and files, but this is not so relevant) will inherit that gid -- and the standard ones that are there from the beginning are also set 2775 (group writable with gid bit set).

This means anyone in staff should be able to install anything to /usr/local with write access to the standard hierarchy of subdirectories (etc, bin, lib, share).