This is a really great infographic, and I like how you don’t just explain how to use them, but also how not to use them!
However, I would disagree that “you can’t make any assumption about the user’s identity” from an access token.
The infographic’s example access token shows a token issued by Auth0 with a client ID subject (sub) and client_credentials grant, meaning not only was an app authorized, it was also an app that did the authenticating! If this was a user-based flow, and the user (resource owner) has delegated their access to a particular application, that required a user authentication in order to authorize that app. I point this out to show that there is still very much a sense in which an access token does encode “authentication” information, because a client credentials flow, by OAuth2 definition, has a resource owner, such as you would get from the access_token’s “sub” claim (or, in the case of opaque tokens, somehow determinable by the resource server) because the resource server needs to know whose resources are being accessed. Of course, some APIs are entirely administrative, everything is specified by URL, and you don’t care about resource owners … but that’s not all APIs.
To quote Auth0’s own On The Nature of OAuth2’s Scopes, “a scope cannot allow an application to do more than what the user can do”—meaning knowing the user associated with the access token is (usually) pretty important!
(And in fact, Auth0’s extensibility is also super-helpful here, because we can add extra claims about that user/resource-owner … like an email address or employee identifier—to the access token. 
)