Why haven’t you familiarized yourself with revision 2.1, if it is so simple (esp. since you already grok 2.0) ? 
But to respond in more serious manner: yeah, sure. Good programmer can write Oauth2 library and implement it and debug it and validate it. Lesser programmer can find and use existing library with even less effort, provided they trust its security. The question is why should either of them be required to waste their time?
To draw a parallel: surely anybody contributing to OSM must be familiar with ODbL and CT they accepted when they signed up. How about we put up a quiz about those documents that people must pass with at least 90% score before they can register account (or continue using the API if they already have the account). The benefits with improving law compliance are obvious. Surely there cannot be any drawbacks to adding such small barriers to entry, right? I mean it would be like 5 minutes (at most 15 minutes) quiz! Much less than implementing and testing Oauth2!
I can see why people might feel that supporting both Oauth1 and Oauth2 is waste, and we should get rid of the Oauth1 that leaves hundreds of duplicate entries in my preferences which I must clean periodically to keep my sanity. But as noted, Oauth2 does not expire tokens, and it adds external code (of dubious quality and trust - until you’ve audited the code, and often even after that) and code complexity, and does not provide extra access security (i.e. one could just reuse e.g. Vespucci bearer token which usually has all rights and do everything they could do with basic auth username/password)
There are some advantages I’d concede to OAuth2:
- Oauth2 for specific app can easily be revoked if you no longer use/trust some app (but so can a regular password be changed and you logged in again in apps you want to continue using - which is only mild convenience advantage at a cost of mildly lesser security)
- you can grant less permissions to some apps (principle of least privilege is real security advantage, but people had that forever elsewhere with PATs without overly complex solutions like Oauth2).
- buggy apps can be centrally locked out by OSM admins by force-removing their Oauth2 configs in case of emergency (but we did that in the past based on user-agents versions too, yes?)
- automatic token expiration forces users to confirm what apps they continue using versus old ones they’re not using anymore, thus locking out unused apps and improving security when exploits are found in them (while one of main selling points, it is seemingly not being used on OSM)
- did I miss any more?
But none of those advantages seem to calls for disabling Basic auth to me?
Oauth2 also has several disadvantages:
- much more complex than PAT / username+password (which we’ll still need to supposedly support for logging in to osm.org website and to authorize those OAuth2 tokens?)
- more code always means more complex (and more complex means more buggy, more bloated, harder to read and more offputting)
- more code also means wider attack surface
- when choosing to “save time and make life easier” by using external Oauth2 libraries, it brings its own subset of disadvantages:
- self contained script is much more likely to be used (and reused) that one that require you to
sudo pip install whateverfirst - external dependencies means now you have to set up alarms to regularly follow another source of upgrades, security alerts, CVEs etc. (or lack of updates if upstream becomes dead, so you have to find a new one and convert to it) - so you increase your maintenance workload (or more likely choose to reduce your security by continuing using old libs with security bugs since “meh it works so why bother”)
- to trust some external code you need to sped as much time to audit it as to write from from scratch from specs, with disadvantage that then you cannot really be sure you’ve done good enough audit. Or you need to blindly trust, which has its own set of failure modes.
- self contained script is much more likely to be used (and reused) that one that require you to