I agree for the most part with Wayne. I might set up a set of "best practice suggestions", recognizing that what works great in some situations is a really bad idea in other situations. For example, in general, I like working with assembly layout sketches, but if you are using dynamic assy motion for visualization or animation, you can't do that unless you have a config that suppresses mates.
Configs are also a great idea, but it only takes a couple of slip-ups to fubar a config, so design tables are often a great way to go. Some configurable parameters cannot be driven by design tables. Everything is a trade off, there are no perfect answers.
Fully defining parts that have in-context relations should be mandatory, and making in-context to moving parts is often a bad idea, but if you have a single instance used to make all the in-context relations, and another instance of the part used for motion, that is ok, but again, it may be difficult to manage if you don't know what's going on.
The stuff that is really important for groups to be doing together is the File Management stuff - how you name and store your files, especially revisions. Also, getting Toolbox to work with a group without causing problems can be a little tricky. Those are things that really do need to be standardized right up front, without any wishy-washy variations.
I think fully constraining assemblies is sometimes a waste of time. There have been suggestions that underdefined assemblies take longer to solve. This is possible, I haven't done any research to verify or contradict this, so I really don't know. Rotationally defining things like pins and set screws can work for or against you, but I think it's more likely to work against you. Having too many open degrees of freedom can make dynamic assy motion jerky and unpredictable (could be caused by a poorly defined pin), but using a plane to constrain a bolt from spinning can cause other problems which may be difficult to visualize immediately.
Also arbitrary rules like "never have three of the same type of constraints, on any one part or sub assembly" don't really get at the heart of the problem and can force people to go way out of their way. For example, is that talking about 3 "coincident" mates of any type or 3 "plane to plane coincident" mates? I regularly mate the first part of an assembly to the assembly planes instead of using the Fixed condition because, well, just because. I don't know why. From a degree of freedom analysis point of view, that's a really bad idea, because a plane to plane coincident mate constrains 1 translational and 2 rotational DOFs, so 3 of those mates constrain 3 trans and 6 rot DOFs, making you overconstrained by 3 rot DOFs. SolidWorks still deals with this somehow, but technically it shouldn't work.
All that to say that the arbitrary rule is not specific enough, but requiring a DOF analysis is too specific. Talk about wasting time! Then you'd have to find out somehow just what kind of DOF overdefinition SW can tolerate and what it can't. And then make sure that everyone follows it. Good luck. I don't know of anyone who does this. Not even me unless I'm troubleshooting something that usually works but in some specific case doesn't work.
Anyway, Wayne I think had it right. Let people work the way they like within limits. Don't let people design assemblies as multibody parts unless it makes sense and the rest of your team can work with multibody parts. Use common sense when it comes to in-context or some of the trickier functions like move face or heavy surface modeling.
If you get crazy with too many rules, the rules may need to change for each project. I say stay flexible, and use the energy you would have used on enforcement instead on educating your designers so they can handle anything.