From my experience, the biggest problem with RFCs comes from the upfront planning costs quickly demanding the feature to be implemented, regardless of the understanding of how detrimental it is in the long run changing later on. There is always that case where someone goes "wait, this doesn't work unless we do X, which hurts us in the long term, so we should change things and do Y". Except now management and the client are so stuck, they demand the RFC regardless of X. Part of this can be mitigated by prototypes, but it is not a fail safe. Or worse, management tries to cut down the costs by involving only one technical person for a short time, who then completely misses a few critical points and the same problem forms.
I guess what I'm trying to say is: no planning or development method is going to magically cure mismanagement, unwillingness to listen and a tendency not to kill the darlings.
Good points indeed. I think you can even further say that people will just make mistakes regardless of the process. If engineers take too long to deliver it’s “over-engineering” or if the deliverable fails at any point the engineers “didn’t know what they were doing”— if requirements change suddenly along with deadlines it’s “mismanagement”. I’m not saying these are not real problems, it’s more that they’re inevitabilities and the processes we come up are just to mitigate them, not eliminate them entirely.
I guess what I'm trying to say is: no planning or development method is going to magically cure mismanagement, unwillingness to listen and a tendency not to kill the darlings.