If you have a relatively modern Databricks instance, when you create a group in workspace UI, it creates an account-level group (which you can see in "Source" column – it says "Account"). So this process essentially consists of two steps: 1) create account-level group if it does not exist; 2) add the group into the workspace. The step #2 is only a display record, it does not create an actual container. (You still can create a workspace-level group through API, but in UI this capability is not available now).

An account-level group can be added to a workspace or may be not added. The content of the group is stored in the account, and will be synchronized across all workspaces. Even if you remove a group and add it back, you will see all users inside, because it comes from the account.

The same applies to all three categories of identities: groups, users, service principals. The main source of truth is the account, but there is also an association between the identity and the workspace, which "mirrors" the account data from the account into the workspace, plus allows for some workspace-level settings. With users and service principals you can clearly see this in the UI, because when you add them to the workspace, the experience will be different for users/SPs already existing in account and not existing. The groups are different in this regard, because the UI just allows you to specify name, and if you enter the account-level group name – boom, you got account content all of sudden. I am not a big fun of how this all is implemented in Databricks; as a Developer I like better the principle of the least astonishment and being explicit rather implicit, but, I guess, this was the sacrifice they had to make when transitioning from the old single-workspace setups to enterprise account setups while trying to keep the existing UX.

So, I guess, the info above gives you some clues why you may see differences in account and workspace client's responses. Account shows "global" user properties, and workspace shows properties set for the user in this workspace (plus duplicating some account-level info).

P.S. Everything above applies to Azure, I don't know if it works the same in AWS.