I think once one uses terms such as "certification", one is implying compliance with some specific requirements. There has to be a clear way to tell whether or not a project is correctly certified, particularly given the idea of self-certification, which forces third parties to be able to spot problematic self-certifications and raise concerns. One has to be able to tell, without subjective opinion, whether a project meets the criteria for certification or not. Therefore everything making up the certification must be 'required' and visibly delivered (or not).
Best practices are of course splendid and there's nothing wrong with saying that a project followed them. If they are firmly defined and the project can clearly be seen to have followed them, then they are not really different from mandatory requirements when setting a certification standard. If they are loosely defined (eg "do your best to X"), or it is hard to tell whether or not a project followed them from the outside, then they may be written down as best practice to aspire to, but should not be used as elements of a certification scheme.
This does not preclude a certification standard that requires a mixture of 'hard' requirements (eg "X type files must be licensed under licence Foo") and 'soft' requirements (eg "the project community must have the opportunity to review X before it is certified"). It just means the 'soft' requirements must be such that an external public evaluator can tell whether or not they were done.