For one, many corporate environments no longer directly tie email user identity and code user identity directly together, they frequently manage them thru a third service that both services connect to instead (e.g. OAuth, ActiveDirectory, etc).
This also only works well if you have: 1) one commit per change, 2) every reviewer has a fully up to date copy of any/all repos being reviewed, 3) a single change only affects a single repo.
The one-commit-per-change (squashed changes) is not always the preference, but it's effectively mandatory since the presentation format for patches only lends itself well to an isolated patch-diff and not a VCS history of changes (ironic since it's intended for the latter). As a great example of this, it's very difficult to compare the differences between the resulting code between two patches submitted to the same thread when I want to confirm a series of corrections to the original submissions were made properly and without side-effect.
Every reviewer having a fully up-to-date copy of the repo the changes are going into works amazingly well for a fully distributed VCS, defining the gatekeeping maintainer's copy as the ultimate source of truth for the "latest". When multiple maintainers for the repo exist, as in most corporate environments and the monorepo organization, this breaks down. The ultimate source of truth for "latest" is now a remotely hosted repository that no one individual gatekeeps. Therefore all maintainers need to constantly duplicate the remote copy and keep it up to date. Either the maintainer is an active developer that's also creating changes constantly and will therefore need to keep two different copies so they can be building and testing their own development changes while keeping a pristine copy purely for review purposes, or they don't usually do a lot of active development themselves and keeping a local copy at all is purely for the purposes of review. In terms of pushing proliferation of copies of the distributed VCS it works, but when more (but not completely) centralized as most corporate environments/users need it's an extra hurdle that impedes the process rather than helping.
For a single change to affect only a single repo requires at the extreme a monorepo layout, or an extremely well modularized design. As noted before, monorepo is very much against the design (few people should need a fully history copy of the entire repo locally with a monorepo, and many maintainers control the same repo) and defining sufficiently modularized breakdown is nigh impossible with larger projects. The Linux project is a great example of this problem, but has a semi-solution that involves having an even larger developer base involved at different levels of a heirarchy, and split repos for "modules" (independently maintained subcomponents or specialty areas) that have to manually cross-related. This is demonstrably problematic even now when a sub-area uses a separate repo and submits wholesale changes to the downstream project, losing almost all of the history and cross-linked-tracking information in so doing. Recognized as a common problem, the community has either gone the monorepo route where all changes go into the single larger repo at the cost of much greater coordination requirements, or the submodule-like route where each sub-part becomes more isolated but may have cross-cutting changes across multiple separate repos. As the repos proliferate in the latter case, individual maintainers often become responsible for a larger number of repos and the other two problems impact them more.
In summary, the mailing list solved a basic problem for a specific narrow use case at a time when technological constraints and solution options were very different than they are now. While the development/maintenance process can still be made to fit its usage, the large scale needs often no longer match, nor do the same technological restrictions apply. GitHub PRs aren't necessarily significantly better, but they do at least move the same concept to a place where an individual user/maintainer can keep their individual source of truth in one place (online), interact with it without needing a full development system/setup present, AND provides options for moving development processes in a new direction. The last has stagnated pretty badly, but throwing it out for a return to a system that has little to no options for modifying the process to meet modern needs seems overly agressive.