Have you logged out and logged back in again since you were added to group A ?
If not, your current login processes will only have the group memberships that it had at the time of login, not any changes since. And any child processes of that login will have the same group memberships (i.e. if you logged into X then every application including your terminal emulator and shell)
You can test this by logging in again on another console or via ssh, or something like exec sudo -u $(id -u -n) -i (to effectively kill and replace the current shell with a new shell - any background processes belonging to that shell will be orphaned)
History
Originally, Unix only had permissions for the owning user, and for other users: there were no groups. See the documentation of Unix version 1, in particular chmod(1). So backward compatibility, if nothing else, requires permissions for the owning user.
Groups came later. ACLs allowing involving more than one group in the permissions of a file came much later.
Expressive power
Having three permissions for a file allows finer-grained permissions than having just two, at a very low cost (a lot lower than ACLs). For example, a file can have mode rw-r-----: writable only by the owning user, readable by a group.
Another use case is setuid executables that are only executable by one group. For example, a program with mode rwsr-x--- owned by root:admin allows only users in the admin group to run that program as root.
“There are permissions that this scheme cannot express” is a terrible argument against it. The applicable criterion is, are there enough common expressible cases that justify the cost? In this instance, the cost is minimal, especially given the other reasons for the user/group/other triptych.
Simplicity
Having one group per user has a small but not insignificant management overhead. It is good that the extremely common case of a private file does not depend on this. An application that creates a private file (e.g. an email delivery program) knows that all it needs to do is give the file the mode 600. It doesn't need to traverse the group database looking for the group that only contains the user — and what to do if there is no such group or more than one?
Coming from another direction, suppose you see a file and you want to audit its permissions (i.e. check that they are what they should be). It's a lot easier when you can go “only accessible to the user, fine, next” than when you need to trace through group definitions. (Such complexity is the bane of systems that make heavy use of advanced features such as ACLs or capabilities.)
Orthogonality
Each process performs filesystem accesses as a particular user and a particular group (with more complicated rules on modern unices, which support supplementary groups). The user is used for a lot of things, including testing for root (uid 0) and signal delivery permission (user-based). There is a natural symmetry between distinguishing users and groups in process permissions and distinguishing users and groups in filesystem permissions.
Best Answer
No, there's no need for a file's owner to belong to that file's group. There's no mechanism in place for checking or enforcing this. Additionally, a user could belong to a group at one time and then be removed; nothing will go through the filesystem to check for files that would be in conflict.
Basically, the owner and group metadata for a file is just sitting there on the disk, and doesn't have any external links. (Tangent: it's stored by numeric user id and group id, and these are resolved by the system when asked.)
Also, only one set of permissions is ever used at a time — if you are the owner, only owner permissions are looked at and the group permissions don't matter. If you are not the owner but are in the group, group permissions are used. Finally, if you are not in the group nor the owner, the "other" permissions are used. If you are both the owner of a file and in the file's group, the group bits don't matter.