OAuth was designed for cases where Application X needs access to resources (e.g., "my photos" or "my email address" or "my calendar") controlled by Application Y and belonging to User A — User A may want to grant access to those resources on Application Y, but he doesn't want to give Application X his actual username/password credentials. So an access token is used as an alternative credential for a resource on Application Y. Access tokens can be revoked independently of username/password credentials and are, ideally, tightly scoped to only allow access to specific resources.
Using OAuth 2 for authentication overloads that model in ways that can be risky. Look at the example above, and imagine it being used for authentication. If Application X uses that access token for authentication, then it's taking a token that grants access to resources on Application Y, and using it to grant access to its own resources. Maybe that's splitting hairs, because the important thing is that we know that the act of granting an access token via OAuth 2 implies that the user has successfully authenticated. The problem is that the access token doesn't say anything about which application the end user authenticated for. So what happens if Application Z also has an access token for User A's resources on Application Y? If Application Z can get Application X to use this access token, then it has access to User A's resources on Application X. That's bad. User A may have trusted Application Z to access his resources on Application Y, but User A certainly never granted consent for Application Z to access his resources on Application X.
OpenID and OpenID Connect are specifically designed for authentication. OpenID Connect is built on top of OAuth 2 so that it can take advantage of existing interactions and flows, but it adds an entity called an ID token, which is an object containing a set of claims about an authentication event. Those claims include an identifier for the user who performed the authentication, an identifier for the server that handled the authentication, and an identifier of the audience of the authentication. This gives an application the information it needs to validate that a user is authenticated on its behalf.