In the authorisation code grant type, where client secrets are meant to stay secret, the user may tell the service that your application is authorised to access certain elements of their account. The important thing here is that they have authorised your application, not any other applications. The client secret is how you authenticate your application to the service.
Acquiring a client secret may allow a malicious application to impersonate your application, and any authorisation it has been granted. This might include replaying access and refresh tokens in order to access a user's account without their permission.
I do believe the attacker would usually need to acquire additional information (e.g. access tokens) in order for the client secret to be useful in practice (I'd love to hear about any scenarios where this would not be the case). Attacks wherein an existing user is lured onto a malicious page (with access to the client secret) may work in some contexts - although there may be complications around the referrer and the page the user is returned to.
The severity ('the worst it could do') would vary depending on the scope, but it's likely to have a negative impact on users of the application. In your examples of Google Drive and OneDrive, it might allow an attacker to read or modify a user's files, for instance, if that's the authorisation they gave.
The implicit grant type is best for environments where a token cannot be kept secret (native desktop, native mobile, client-side browser, etc).