When do you use OpenID vs. OpenID Connect

I don't think either of the other previous responses answer the question, which is asking the difference between OpenID Connect and OpenID 2.0. OpenID 2.0 is not OAuth 2.0.

OpenID 2.0 and OpenID Connect are very different standards with completely different parameters and response body formats. Both are built on top of OAuth 2.0 by putting additional values into otherwise valid OAuth 2.0 requests and responses, in order to provide identity information needed for authentication (whereas OAuth 2.0 only provides authorization, not authentication). OpenID Connect improved naming and structure of OpenID 2.0 fields and parameters in order to be easier to use. I can easily read the OpenID Connect specification and understand what all the values are used for and what to set them to, but trying to read the OpenID 2.0 specification is a bit more difficult and convoluted.

At this point the choice is easy, OpenID 2.0 is deprecated. You should use OpenID Connect.

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer.

To some extent you can mix authentication and authorization, but that's a source of confusion. In your case, you apparently want to authenticate users with "Google, Twitter,...": you want Google (or Twitter) to tell you who the user is, but not what the user should be allowed to do; you want these external providers for authentication, not authorization.

Another way to see it is the following: a user connects to your server S. Server S offers some "services", i.e. will do "things" when asked for; however, it won't accept to do the same things for everybody. Let's assume that you found it fit to give control of what S may do or not for each user to another system which we will call R. R may or may not be the same computer as S, but let's think generically and assume that R is distinct from S. From the point of view of S, the needed information is in scope of authorization: S wants to know whether the call is to be granted or not. So there will be some authorization protocol going on between S and R. Possibly, S and R won't talk directly to each other, but only through messages ("tickets") which are transported by the client; that's a technical detail.

However, to decide whether a given request to S should be allowed or not, the authorization server R must know who is sending the request, because the answer depends on the user's identity. Therefore, R will need to authenticate the user; or, more generically, to talk to an authentication server T. T is responsible for making sure that the user is indeed who he claims to be. An authentication protocol then occurs between R and T.

In your example, R is your authorization server, while T is Google/Twitter. You would use OpenID between R and T, and OAuth between S and R.

OpenID Connect is when S wants to do some authentication as well; S then uses R (who "speaks OAuth") and infers that if R allows the request, then R must have done some sort of authentication of the user; so S decides that the user is indeed who he claims to be, since it (implicitly) convinced R.

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. OpenID connect is in fact the child of OpenID. See OpenID-Connect-Lecture-for-MIT, slide 33

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect Core 1.0 - draft 17

Things is, OpenID connect provides you a "standard" way to obtains user identity. If you use OAuth and the API, you should adapt your request for each ressources, which may not always provide the same information or may change over the time. And conceptually, you use OAuth to be allowed to use an API, not to authenticate an user.

As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. OpenID Connect Core 1.0 - draft 17

Note that, OpenID connect provides an id_token with some information about the user. But if you want the whole set of information, you still need the access_token to request the the OpenID provider to get the userinfo (which confuse me the first time I see it). See 5.3.1. userinfo request in the draft