We are looking at the overwhelming use of boilerplate in the RFP process. Boilerplate can be a good thing: when your RFPs are all similar re-using portions saves time. Also, if you are operating in an environment which has great amounts of legal process requirements boilerplate is helpful in making sure you "dot all the i's." This may be the case in this example RFP. It is 66 pages, the term in the title is mentioned only 18 times, and on only three pages is the term used not as the title of the document or in a different context. Basically 3 of 66 pages are directly descriptive of the project, which means that 95% of this document is process, boilerplate and legalese.
From the prospective of the firm reviewing this RFP, this is a lot of information to slog through just to get some sense of the actual subject of the RFP. Around points where it is considered necessary to have a lot of specific "wrapper" language, the boilerplate problem may be helped with some structural modifications. Lead with the subject, as an introduction or a intro section. Likewise, if possible, drop the boilerplate stuff into the end as an appendix. This way it is in the document but not in the way of the documents main purpose.
If the response to your RFP was just a boilerplate with your RFP project's name inserted you would not appreciate or take seriously the response. This is the danger in boilerplate: In the request for proposal process the quality of proposals received is proportional to the amount of effort put into the RFP.