Hi Grant, thank you for engaging with the concerns here!
About the naming, RfC can (somwhat unhelpfully) mean either the TechCom process or feedback gathering and discussion in general. Up until about 2015, we had an unstructured RfC process for large-scale decisionmaking, which was used for both architectural and non-architectural decisionmaking, including things such as switching from Bugzilla to Phabricator and switching from Gerrit to Phabricator (eventually rejected, after the first few experiments turned out not so impressive while Gerrit improved). (I don't think there was any kind of explicit process for switching from SVN / Extension:CodeReview to Git / Gerrit, the third past change comparable to the one we are discussing now, but it was preceded by massive amounts of mailing list discussion.) After ArchCom / TechCom was established, it took over managing RfCs related to system architecture, which in practice is almost all of them; we had a separate Phabricator board for TechCom RfCs and generic RfCs (the latter was more recently renamed to Proposals to reduce confusion).
So I don't think most people talking here about an RfC mean there should have been a TechCom RfC, but that there should have been a participative decisionmaking process (the Foundation has recently started calling these consultations, in part to avoid the different and very specific connotations the term "RfC" has on content wikis). Both because we have an intricate and diverse tech ecosystem with many different niches with different requirements, workflow needs and contributor backgrounds, and the information needed to understanding that environment is distributed in many heads, and we need to bring it together to make the right decision; and because that's what aligns with the culture and values of our movement, and open source in general. The Foundation's guiding principles say that the WMF should share decision-making power with the community; the movement strategy principles likewise ask for participatory decision-making. More generally, and at the risk of being mistaken for a Marxist :), open source is one of the very few special environments where workers can truly own their means of production, and excluding them from that ownership will alienate them from their work. Fundamental changes to your work environment happening over your head are disempowering and disaffecting, even if they are otherwise reasonable changes. (It doesn't help that this is happening in the context of the Foundation having announced other, non-technical fundamental changes, which are far more controversial. So tensions were high anyway.)
I find the current course all the more unfortunate because I don't think there's all that much difference between a consultation and a precommitted decision in terms of what specific actions will be taken. A consultation would include gathering feedback on how people used Gerrit (or whatever else they were using), pain points and high points, things they would like to see improved and things they would like to be preserved. It would gather feedback from people with experience with GitLab. It would result in creating some kind of feature comparison matrix, with a summary of what we would gain and how we'd minimize losses. It would set up a trial GitLab instance and migrate some projects that volunteer for it, to verify that our understanding matches reality. These are all things that will mostly have to be done anyway! So IMO the best course of action would be to un-commit to a specific outcome, set up a working group (ideally with some volunteer participation) to do the work of surveying, requirements gathering, feature comparison and testing, with various feedback opportunities along the way; and have them make a go/no-go decision at the end of that process. Again, I think most of those steps would be necessary in some form anyway, so we'd get a more aligned and empowering process almost for free.