There are at least two tricky aspects of this:

• Security: since clients (AIUI) have no way of safeguarding client secrets, any attacker who extracts the OAuth credentials out of the app will be able to obtain the given OAuth permissions from any user, just by making the user visit the attacker's website (and then issuing it the right redirect). That might be acceptable for very limited (readonly) permissions. It's very abusable for edits / logged actions (not to mention sensitive actions).
• Trust: without the permission dialog, the user will have limited understanding of what's going on (e.g. what the app is / isn't allowed to do in their name), so they might be less likely to trust and use the app. (This is a big deal if you are an admin etc. and know you will be held responsible for bad things that happen via your credentials.) Is that offset by the value gained from the lower-friction login/signup process? I'm not sure.

(We allow skipping the dialog in certain limited (arguably too limited) circumstances, if the user has already gone through the dialog some time in the past. That's discussed in T91801: Support a more user friendly "re-authentication" flow for returning users.)

I think the relevant spec is RfC 8252 - OAuth 2.0 for Native Apps which basically says what @JTweed-WMF already said elsewhere (this should only be done for HTTPS redirect URIs).

8.6. Client Impersonation

As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the
client can be assured. This includes the case where the user has previously approved an authorization request for a given client id -- unless the identity of the client can be proven, the request SHOULD be processed as if no previous request had been approved.

Measures such as claimed "https" scheme redirects MAY be accepted by authorization servers as identity proof. Some operating systems may offer alternative platform-specific identity features that MAY be accepted, as appropriate.

Pinging some people mostly just for the record, since this was actually discussed on Slack already: @EMill-WMF @Catrope @Seddon. We'll go ahead with adding this option as something that can be enabled for first party clients only. Let us know if you disagree.

Implementation notes: the option should only be available to clients administered via T413288: Allow managing OAuth apps programmatically, and it should only take effect for HTTPS redirect URIs.

Change #1311117 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/OAuth@master] Allow skipping authorization dialog for some clients

https://gerrit.wikimedia.org/r/1311117