Usually those implementations redirect the user to a separate authentication system. OAuth2 only handles authorization and not authentication. Upon successful authentication, the user gets redirected back to the OAuth2 request which then generates the authorization code.
When the user is already logged in via a cookie set by the authentication system (i.e. an existing valid session), they don't get prompted for a password again; the authentication system will simply redirect to the OAuth2 request url. The typical OAuth2 implementations shouldn't be reading the authentication cookies directly.
The "password flow" in OAuth2 is really a special case for those who want to bypass the separate authentication system and use OAuth2 directly for both authentication and authorization.
I can say that recently LinkedIn has asked me to reauthenticate on multiple occasions in the same session. I've had the same for Google but I have not tried recently. I'm aware that Twitter and Facebook allow you to do so, but I propose that none of the above give scopes without authentication that allow you to perform actions that charge an account.
That said, I agree that some of the giants are fine with using cookies for auth in OAuth2. And while that indicates that this is a possible use case, OAuth2 is capable of being used in many ways and Digital Ocean's usage still doesn't make much sense.
They all let you approve if you are already logged in.