> If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection)
This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret.
I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.
PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.
For what? For just authenticating a client application to a server without getting access to any user data? By all means. You usually don't need the client credentials in OAuth 2.0 if you don't want to use it.
But if you want access to user information, you can't just give access to an app that has a shared secret key to a all user data for every single users in the planet. You need to authenticate the user somehow, and sharing the user's password directly with the app is not a good idea for many reasons.
Even if you trust the app to be "written without any bugs", the moment you allow the password grant in OAuth, your service cannot use CAPTCHA, MFA or Passkeys efficiently. The password grant does not allow any of these, so this app that you've let through becomes the weakest link for all cybercrime groups that want to attack your service.
This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret.
I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.