This isn't peculiar to Raspbian or even GNU/Linux; evidently it's used on [OSX](https://apple.stackexchange.com/q/130685) too, although perhaps not the same way.   Both operating systems are a form of [unix][1] -- 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][2] 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](https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html)

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`).

----------


  [1]: https://en.wikipedia.org/wiki/Unix
  [2]: https://wiki.debian.org/SystemGroups