What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.
That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.
Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig.
If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail.
The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods.
The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.
Yes, the BFDL maintainers can continue to operate in whatever system they're given, but the more transparent the system is, the more likely they are to be discovered and the issue corrected.
I do agree that the E-mail workflow offers (a few) advantages, but the lack of inherent transparency in the tooling tends to be quite troublesome. It also doesn't inherently offer easy integration with automated testing systems or easy audit and compliance logging.
It's more suited for free software projects like Linux & Git where the participants don't want to be locked out of all their historical discussions just because some company does badly in the stock market, as opposed to being 100% archived in hundreds of places via an open protocol, and trivial to migrate somewhere else.
I'm just saying the problems you had with it seem to come down to a completely dysfunctional corporate culture, not patches over E-Mail.
Sure if you're working with such monumental assholes that they're just going to passive-aggressively and conveniently discard whatever you tell them over E-Mail / IM / at the water cooler that's pertinent to their work area and need to essentially CC their manager on all correspondence, and are using PRs as a way to do that.
Then sure, then an E-Mail-based workflow probably isn't for you, although you could use git-format-patch to CC both your and their manager on every patch you send to achieve similar results.
In my experience most attempts to move these sorts of teams towards real revision control and development practice lead to an extinction event in which they practice every form of hazing possible to maintain control, requiring careful management. Think extreme code-format nitpicking (combined with a lack of automated tooling or a styleguide that would let "others" get it right), followed by appeals to whichever authority maintained their team, outright hostility, and eventually ultimatum or holding the code hostage.