This all is solvable, both through discipline and tools. But if a VCS has a built-in capability to alleviate this, it's a good thing.
Having hundreds of committers merging into one branch is problematic. Perhaps splitting the repository into smaller parts does have its advantages. Monorepos often have the architectural split of the software while throwing away the advantages of the split at the vcs level. But there is also other large software, developed by hundreds of people, that cannot meaningfully split into separate git repositories without messing about versioning and releasing. The Linux kernel is such a system. They use a loose network of repositories -- mostly a hierarchy -- to pre-aggregate merges. Git is well equipped to handle different approaches -- separation of mechanism and policy.
I am looking forward to learn how a central but cloud-native VCS will improve on that.
The number of companies that implemented their own merge queue is too damn high.