Waiting for Yarn v2/v3 support in Dependabot has been a saga.
The short answer is that the Dependabot team can't support all the ecosystems people want without hiring a dozen engineers who have expertise in those ecosystems. The best choice IMO is to move to a model where the community (and ideally the package manager maintainers) can implement their own updaters (ideally using the package manager directly, so support for yarn whatever can just be "update the yarn Dependabot updater to use the newest version of the yarn updater" without the Dependabot team having to care). GitHub even has a platform for running untrusted code, so...
Disclosure: was once my problem, no longer :)
Reading between the lines from comments in that thread, it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic to do in-place lockfile updates behind the scenes. I'm sure it is nice to avoid checking out the whole repo, but it would also multiply the maintenance workload exponentially.
https://github.com/thepwagner/action-update being an example of this (and showing go, docker)
> it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic
The entire maintenance burden of dependabot is "reimplement logic that package managers already do to determine the update strategy." Using package managers functionality for this would indeed make this a lot easier, though even then package manager support for specific things might not be universal.
That said, it's possibly easier to go to the package manager and say "we'd like to implement/for you to implement feature X that will enable Dependabot as well as the underlying functionality Dependabot was missing, that your users probably already want" than the opposite problem of people asking Dependabot to write a bunch of ruby to re-implement something that already exists.