An RFC, request for comment, is where engineers make technical decisions. A TPM who waits for the RFC to close before engaging is reading a decision that has already been made. By then, the interesting options are gone.
I read RFCs for two things: assumptions about timeline and assumptions about dependencies. Engineers writing RFCs are often optimistic about both, not because they are careless but because they are thinking about the technical problem, not the coordination problem. That coordination view is what a TPM brings.
The useful questions in an RFC review are not about the technology. They are about the interfaces. What does this design require from other teams? When does it require it? Is that a safe assumption given what those teams are committed to? Those questions change designs more than technical objections do, because they connect the RFC to the reality of the program.
The other thing TPMs can do in RFC reviews is name the trade-off the author is avoiding. Most RFCs have a hard choice somewhere in them that the author is not ready to make. Naming it is uncomfortable. It is also the most useful thing you can do, because the choice does not go away. It just gets made later, under more pressure, with less time.
If you are not reading the RFCs in your program area, you are finding out about technical decisions after the fact. That is a manageable position but not a strong one.