None of these ideas are really new. See e.g. Alternative formatters for generated code, like `ruff format`? for using ruff as a formatter, and some later comments on linting and import sorting.
For the rest it’s hard to find clear conversations, but I’ve been involved in at least some of them and from what I (possibly incorrectly) remember:
Using pre-commit hooks in CI I think was discussed at some point but I’m not sure there was any resolution. At the moment things that run in pre-commit are already run as separate linters, which you can argue is nice because you immediately know which thing is failing. I believe we also use an extra action to show as github annotations where each failure is occurring, and I’m not sure if this would work with pre-commit or not.
Linting performance has been discussed (by me at least) in a few venues and at the time ruff was a bit too new to switch to. I think there’s a good case to be made to revisit this.
For CI dependencies, I don’t remember any discussion but I’m not sure exactly how much value I see. Most things are already not pinned and will use the latest. The exception here pre-commit hooks, maybe could do something about this but I don’t believe dependabot supports updating pre-commit hooks. Renovate could work but I think easier to not worry about an external system just to manage this and just run pre-commit auto-update in a GitHub Actions workflow and be done with it. But I’m not sure what the current workflow is, it could be they are already updated at specific times, e.g. before / after a release. Not sure on this.
CI gating has also been discussed before (somewhere…) but IIRC it was decided against because sometimes (e.g.) a linter can fail due to no problem in your branch but a problem elsewhere and you definitely don’t want to stop the tests from running in these cases.