The idea of a DSL over YAML is also a good one. Jenkins got this right, using a DSL on top of Groovy. This allows for Jenkins build script libraries[1]. I have used them in the past, and they were a joy. They allowed for standardizing builds across many different small git repos, each with their own terraform or helm chart. I miss this feature in GHA.
This is a topic of debate in my current job. We use Jenkins Multibranch Pipelines and don't want to discard all that work, but we also don't want developers doing release management based on the Jenkins UI/UX. It seems logical to use GHA with local runners to call Jenkins via bash scripts running curl commands, except for how "Rube Goldberg" that sounds. But it seems like everything is like that these days, and all you get to do is pick your poison.
There's also the problem of Jenkins in general, that it's a mature product and you never know if the one plugin you depend on is going to stop being maintained. Or you know you have CVE's but can't upgrade without running two environments, one production and one with all the plugins updated. Or you're chasing down an issue only to find bugs that have been open issues for several years.
It honestly sounds like you've simply outgrown Jenkins in terms of scale. Jenkins is an excellent product but it's not very good at dealing with more than a pizza sized team's worth of CI pipelines. Once the number of teams grows past four or five, you either split them off into their own Jenkins server (which I unfortunately recommend) or you face the pain that follows.
1: https://www.jenkins.io/doc/book/pipeline/shared-libraries/