What does GID mean?
Every process in a UNIX-like system, just like every file, has an owner (the user, either real or a system "pseudo-user", such as daemon, bin, man, etc) and a group owner. The group owner for a user's files is typically that user's primary group, and in a similar fashion, any processes you start are typically owned by your user ID and by your primary group ID.
Sometimes, though, it is necessary to have elevated privileges to run certain commands, but it is not desirable to give full administrative rights. For example, the passwd command needs access to the system's shadow password file, so that it can update your password. Obviously, you don't want to give every user root privileges, just so they can reset their password - that would undoubtedly lead to chaos! Instead, there needs to be another way to temporarily grant elevated privileges to users to perform certain tasks. That is what the SETUID and SETGID bits are for. It is a way to tell the kernel to temporarily raise the user's privileges, for the duration of the marked command's execution. A SETUID binary will be executed with the privileges of the owner of the executable file (usually root), and a SETGID binary will be executed with the group privileges of the group owner of the executable file. In the case of the passwd command, which belongs to root and is SETUID, it allows normal users to directly affect the contents of the password file, in a controlled and predictable manner, by executing with root privileges. There are numerous other SETUID commands on UNIX-like systems (chsh, screen, ping, su, etc), all of which require elevated privileges to operate correctly. There are also a few SETGID programs, where the kernel temporarily changes the GID of the process, to allow access to logfiles, etc. sendmail is such a utility.
The sticky bit serves a slightly different purpose. Its most common use is to ensure that only the user account that created a file may delete it. Think about the /tmp directory. It has very liberal permissions, which allow anyone to create files there. This is good, and allows users' processes to create temporary files (screen, ssh, etc, keep state information in /tmp). To protect a user's temp files, /tmp has the sticky bit set, so that only I can delete my files, and only you can delete yours. Of course, root can do anything, but we have to hope that the sysadmin isn't deranged!
For normal files (that is, for non-executable files), there is little point in setting the SETUID/SETGID bits. SETGID on directories on some systems controls the default group owner for new files created in that directory.
I think you mean the "SGID" bit of a file, which is not the same as its GID.
Here's a typical file on my computer (output of ls -l):
-rw-r----- 1 bristol users 16 2012-07-23 11:36 file.txt
abbbcccddd <-- See explanation below.
If you look at the first 10 symbols,
(a) - : This is just a plain old file (as opposed to a directory, symlink, pipe etc. ...)
(b) rw- : The owner can read and write this file, but not execute it. The owner is "bristol" as you can see later in the line.
(c) r-- : Members of the group this file belongs to ("users" in the example) other than the owner can read, but not write or execute this file.
(d) --- : Anyone else can't access this file at all (except root of course).
The GID field is the one that tells you which group this file belongs to - in this case "users".
The field you probably meant, based on your description, is the SGID bit, and here's a better explanation than I could come up with:
http://www.codecoffee.com/tipsforlinux/articles/028.html
The short version is: if an executable file has the SGID bit set, then anyone who's not in the group but can execute this file temporarily gains the rights of this group while the program is executing.
For example, if you have a group "spool" that can read and write files in the print spooler directory, you don't want just anyone to mess with this directory but you do want them to be able to print files, you can make some printing program or script have group "spool" and set the SGID bit and when anyone launches this program, the program can now write to the spooler directory without the person running it gaining full access.
The GID is, as you have found, the ID number of a group. It is simply a convinient way for the OS to express the (user) group associated with something (a process, a file, etc.); instead of a potentially long string identifier, it can be expressed as a fixed size number.
In a file permissions value of four octal digits (for example, 0755), the third digit specifies the group's permissions to the file. If you omit the first digit, it's the second digit that specifies the group's permissions. Note that files and directories are treated the same in this regard, but that the exact meaning of each permissions bit is somewhat non-intuitive in the case of directories.
The two concepts are related, but serve very different purposes.
As for your question "is it even important to set those permissions?"; they are always set to something, but since in most cases the initial digit is 0 ("nothing special"), it tends to be omitted for brevity. Whether you need to specify some other value depends entirely on the usage pattern for the file or directory in question.