Correct, you cannot add SSH keys to an account using OAuth 2 (or any other form of delegated access).
When we added support for privilege scopes, we had to deprecate some existing functionality that would allow scoped session from broadening their privilege levels. These include:
the ability to create new OAuth consumers
create team API keys
change a user's password
change a user's email address
uploading new SSH keys
Consider a hypothetical "oauth_consumer" scope that would allow a client to create new OAuth consumers (this was previously possible). You could then create a new consumer that has a different set of scopes (or none at all, which implies all), then obtain an access token for this new consumer and be able to escape, as it were, the originally approved scopes.
Email address mutation would allow a client to trigger a password reset for the user, direct the email to a malicious address and change the user's password and log into their account without restrictions.
Team API keys do not have support scopes and so for similar reasons a scoped session should not be able to create them.
Essentially, scoped sessions should not be able to create new login credentials.
One could say that the newly create credentials (e.g. an OAuth consumer) should therefore also support scopes and automatically get the same scopes as the "parent" session.
We did consider this, but that lead to the issue of what to do if the user then revokes the original token. Should that cascade on and also revoke any new credentials created as part of that session? The user may not be aware that any were created and so we couldn't leave it to them. Otherwise revoking a client would become very hard.
Now we get to SSH keys which, like API keys, OAuth tokens and passwords, are very much credentials used to authenticate and access a user's data with and so to avoid the above issues, we felt it necessary to make that off limits to scoped OAuth sessions.