1)This is a silicon proven IP no need to do rigorous testing and coverage – Hold on are you sure if all the feature crosses are validated by the IP vendor in the silicon.
2)RTL is the one that is taped out and converted to a product no need to review verification environment, test plan review is sufficient --- 70 % of time is spend on verification out of which considerable amount of time is spend on developing test bench, re-usable and well architected test bench helps you to achieve your verification objectives in less time and in maintenance of your code in longer run.
3)This is a working legacy code keep it --- Legacy code with defect in the architecture is difficult to maintain and doing an enhancement on the code is a nightmare. Consider re-coding sections of the legacy code when you have to do an enhancement in the code to support a new feature.
4)Start the implementation and study the protocol as you go. We want you to be productive from day1 --- A big no!! You cannot architect an environment without understanding the protocol completely and you will always end up with a situation were you were not informed about a requirement.
5)Good verification engineer is the one who hit lot of bugs – Hold on you can have a bad designer who can make many mistakes, making ordinary verification engineer look exceptional.
6)No need to have an architecture document for a verification environment --- Reverse engineering a code to find out the verification environment architecture is not an easy job. It is a pain to understand the architecture of an environment after reverse engineering a code. Always document the architecture of your verification environment if possible document a class diagram.