I will try to provide some hints. Please understand that I cannot give an estimate about how "big" a performance impact may be. If the system is not highly loaded or you have an incredible amount of objects you will most likely not notice any changes in the performance. However it definitely makes sense to build everything with keeping the performance in mind to be safe in the future or when peaks occur.
1.) The order of items in a list does matter. If you have a very big list with lets say 5.000 entries and every request is checked against this list you will notice a big difference when you sort the list by "popularity". You should always try to estimate which list entries (or criteria in a rule set/rule) may hit very often, and place these entries close to the top.
I had one example where MWG was deployed for multiple customers. There were one or two big customers causing 90% of the traffic and a few dozens of other smaller customers. Then there was a list of rules applies which tried to find the customer name (based on source IP) and apply some actions. With the big customers at the end of the list MWG had to perform dozens of checks for all the requests form the big customers, which didn't make any sense.
If you can assume that some entries will be hit more than others, make sure that MWG hits them first :-)
2.) For every HTML Element that is in the setting MWG will cause a new "embedded" cycle and run the HTML element through the rule engine, applying all rules that are valid for the embedded cycle. So yes, this will make a difference. Reduce it to the minimum of HTML elements you would like to check.
3.) From a performance perspective I do not think this will make a big difference. I believe if you disable a rule MWG will notice this and skip it, which is a very very simple lookup and not very expensive from a performance perspective. However if you have 1000 disabled rules walking through the rule engine may be slightly slower (probably not noticable) compared to not having those rules at all. I would leave everything disabled that you would like to enable again some day.
If you want to just keep something because maybe you want to add it again or want to use it as a template you could export the rule group to the rule library and delete it. So it is still available for import, but does not hang around useless in the production policy.
4.) I don't think this will make a big difference. In this case I would design the rules in a way that they make more sense from a readability perspective, rather than worrying about performance. It does not make sense to optimize your policy for performance so much that you can't read/understand your rules any longer.
5.) It does not make a difference. I would use "Continue" or "Stop Rule Set" depending on the rule and the question "is it likely that further rules will be added below, and if so, do I want to trigger (Continue) or skip (Stop Rule Set) them?".
6.) No recommended amount. You can basically feel free what you want to do. However I find "is in list" far more readable than a couple of ORs. So I usually prefer to create lists when
- I have more than 3 entries
- I am uncertain whether more entries will come later
For example if I want to whitelist everything for Facebook and the associated URLs it does not make sense to say URL = facebook.com or URL = fbcdn.akamai.net or ..., but I would create a list of "Facebook Hosts" so you can see and read the rule very quickly and understand what it does. As long as it is just a simple decision or something that does not fit in a list (Command.Name = GET OR Command.Net = HEAD) I would prefer using the criteria rather than a list.
The most important note is that you place "cheap" decisions to the top, and "expensive" decisions to the bottom. Especially blacklist or whitelist entries should be placed on top. URL filter decisions is also done pretty quickly, while AV scanning takes its time. So if there is any rule that could prevent you from filtering for viruses (because it is blocked anyway), place it in front of the virus filter rule sets. If you watch out for those "bigger" performance traps you should be pretty safe.