I suspect that recruiters are going off name-recognition: there're some interviewers that they know & like, and so they assign candidates preferentially to those interviewers with digging into the database to see if there'd be another equally-qualified engineer.
Many other things work like that too. If you do code reviews quickly, you'll get a reputation as a good reviewer, which means...more code reviews. If you always know the answers to people's questions, it means you'll get more people asking you questions. If you're a UI wizard, it means you'll always be assigned UI work, even if you want to do something else.
The usual way out of this is to learn to say "No". That's how I escaped the UI trap, and I've done it to get out of code review & question overload as well. I suspect Rachel's problem could've been solved by setting her interview constraints to 0/week, which (if done by enough people) would've also forced the recruiters to look further down the interviewer database and find untapped engineers for interviews.
My gut tells me that most likely the lack of quality coming out of the recruiting team was burning people out on teams. If an engineer thinks there is a 1:100 chance the person will get hired and they have to invest 2 hours in each person they'll never bother. If the recruiting focuses on quality and gets it down to less time and higher acceptance rates the engineers might (reluctantly) be more comfortable "spending 2 hours" on a screen rather then "wasting 2 hours".
Observing the process sourcers and recruiters go through to improve their quality has been very interesting to me. It takes time for them to calibrate to the role (just like interviewers), and while my Silicon Valley experience amounts to one company, my general impression is that many engineers at other companies just don't appreciate the effort they go through to calibrate to the role, and many engineering departments don't put in the effort to help them get to being great.
While there are occasional dips in quality as sourcers and recruiters try new strategies (maybe going deep on release engineering talent in the games industry in Alabama), I'm willing to accept this because I understand that they're trying to get better at what they're doing - it's just like they don't (seem to) get angry with me when I fail to get good signal on whether a candidate is good or not, possibly because I was trying out a new question.
Assuming that the problem was a lack of quality AND that this is the recruiting team's fault sounds unjustified - I assume that Google takes recruiting seriously and puts at least as much effort into calibrating their recruiting team as they do on calibrating their engineers for interviewing.
I see no evidence that they were doing a bad job on quality. They do as good a job as they can. But recruiters are fundamentally unable to evaluate technical skills. The OP would be the first person that interviewee talked to who actually could judge technical skills, and her job was to be a rigorous filter, to remove the egregious candidates.
The other team members should realize how important it is to do the screening instead of pretending working on code was more important.
That part of the process was not being criticized here, but I would agree with it.
If an engineer thinks there is a 1:100 chance the person will get hired and they have to invest 2 hours in each person they'll never bother.
Trust me, engineers are made aware of the statistics. But it is one thing to see them in abstract, and another to look through all of the candidates that you, personally, have talked to.