This may or may not be an OS dependent feature, you haven't given enough details to tell.
The sgid bit on an executable causes it to run in the file's group even if the user running it isn't in that group. (set group id) If it's not executable, the sgid bit is mostly moot.
On a directory, the sgid bit has been repurposed to control group inheritance within the directory. If the sgid bit is set on a directory, files created in the directory inherit the group (but not the group permissions). The point of this is that if you have a shared directory used by users in a group, they can all set their umask to 002 instead of 022 and all edit the files in the directory without needing to constantly fix group permissions. (Without the umask change, this is less useful.)
So possibly on the two systems you were looking at, one had the sgid bit set on the directory you were testing in, and one did not. This feature hasn't been around forever, so if one of the systems is sufficiently old, it may not support sgid directory inheritance. (But it has been around almost forever, so this is unlikely.)
This in no way makes sgid useless, I'm not sure why you would think that, you didn't explain what you think is useless. Note that if a file has a group owner for a group you are not in, you won't be able to make the file sgid without changing the group owner first, and if a non-root user copies the file, sgid is dropped.
