I suspect job definition would require re-work to support multiple SCMs. It's not un-doable but no one has put forth effort to work on it. I think it's best to be a core Jenkins feature, and get the review necessary to support the workflow. I don't think it's too far out there, and I think even changes could be handled properly that way.

I think that this extension of features is worth doing even though pipelines support multiple repositories, as pipelines are more complex and not for everyone.

Pipeline is Groovy, which is easier than many scripting languages. If it's too complex for users, they probably need to find another industry.

As Pipeline is the way of the future with Jenkins, it is an acceptable solution to this problem to recommend Pipeline. With 2.x, Pipeline becomes part of the product (a core plugin). It's available as a plugin now. My team accepted there is no reason to put an enormous effort into 1.x functionality and has moved on to using Pipeline.

Since pipeline supports multiple git repositories, that is the preferred solution for this.

Supporting multiple repositories from inside the git plugin will introduce too many compatibility problems for the git plugin.

Yes, the pipeline script supports multiple git repositories to be checked out (cloned) into the corresponding the sub-directories.
But how should one write this script so that the polling of these repositories would trigger the job in case of updates? Please, see my question in details here: https://stackoverflow.com/questions/47439718/trigger-a-job-by-polling-multiple-git-repos-inside-jenkinsfile.