Relevant POSIX definitions:
File Owner Class
The property of a file indicating access permissions for a process related to the user identification of a process. A process is in the file owner class of a file if the effective user ID of the process matches the user ID of the file.
File Group Class
The property of a file indicating access permissions for a process related to the group identification of a process. A process is in the file group class of a file if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. […]
Note the classes are named "File Owner" and "File Group". There is no "owner" in the latter term. Where you see "file owner" (or "file's owner", like in the definition you cited) it's all about the user, noting about the group.
Yet another POSIX definition confirms this interpretation:
File Permission Bits
Information about a file that is used, along with other information, to determine whether a process has read, write, or execute/search permission to a file. The bits are divided into three parts: owner, group, and other. Each part is used with the corresponding file class of processes. These bits are contained in the file mode.
[…]
[Emphasis mine]
It says "owner, group, and other" where we could informally say "user, group, and other".
People who say 'File owner… You mean the user owning the file? or the group?' are not fully POSIX-compliant.
The definition for sticky bit uses the term "file's owner", it doesn't use the term "file's group" (or "file group"). This means it has nothing to do with groups, groups are irrelevant to how the sticky bit works.
The answer to your question
why does sticky bit still work here?
is: because it doesn't take groups into consideration at all.
Is this a definition error or my misunderstanding?
The definition is consistent with this behavior because it refers to "file owner", not once to "file group". There is no definition error.
To be clear what the cited question is about.
Without the sticky bit set for the directory, without ACL for the directory, this is how its permissions work:
- Are the user in question the one that owns the directory?
- Yes → The owner's permissions matter. Nothing else matters. End procedure.
- No → Are the user in question in the group that owns the directory?
- Yes → The group's permissions matter. Nothing else matters. End procedure.
- No → The other's permissions matter. End procedure.
Common permissions for a directory are rwxrwxr-x where the second rwx is the group's permissions. w in it indicates any user in the right group can add files to or remove files from the directory (almost, because for the owner the first w matters, not the second; if it were r-xrwxr-x the actual owner could do less than other members of the right group, even if the owner was in the group).
When the cited question reads
there is a directory /project, owned by group IT. Both user peter and stewie belong to the group IT
it's to indicate both peter and stewie can probably delete any file in the directory, including the other user's files. The task is to change it so
the files created by peter cannot be deleted by stewie
Before setting the sticky bit the "file group" for the directory (which is also a file) matters when it comes to deleting a file from the directory. After setting the sticky bit the situation changes. The definition says "only the file's owner, the directory's owner, or root user can […] delete". The dependence on the "file group" no longer holds.
