I've poked around but havent been able to find anything regarding best practices with Rule Machine. There are plenty of posts asking about how something works, but nothing in terms of the best way to do something. Basically "Just because you can doesn't mean you should".
I guess what I'm really after is a list of things to NOT do. (Ex: dont run a rule with infinite repeats for 100+ lights). Something that outlines the possible performance impacts of writing a rule in a particular way.
Like everyone else, I am new to rule machine. I have a tiny bit of programming background which has helped (and part of the reason I went with Hubitat -- in addition to everything running locally). Because of this, I tend to think about efficiency, but to me, that is more about elegant coding than just a bunch of statements to get it done. But that may not translate so well to this platform.
Quite a few forum posts and FB posts seem to indicate the Hubitat has limited resources available (Memory/CPU) for performing functions and that different rules can end up impacting the availability of those resources.
So, is there a document that I just missed, or something coming in the near future, that may give a bit more insight as to how rules SHOULD be built to optimize performance?
Cheers!
I'm not aware of any such document, but I think the best thing to do is to read the docs and have a good reason if you deviate from the general format of the examples they provide. The Rule Machine author, Bruce, also recommends keeping rules short and simple--there's nothing wrong with having multiple rules that work together to accomplish the same task (and it's often easier; multiple instances of a rule running at the same time is both possible and potentially confusing, and multiple, unrelated triggers--one thing that can cause this--may make it hard to determine what to do in your "Actions to Run" section, assuming you fork it with IFs depending on what you want to happen when).
I usually point people to the forum thread instead of the actual docs (general RM docs or Rule 4.0 docs) since there are in-line screenshots and you can read more posts from users and staff in the thread later:
But beyond that, I'd say you have the right ideas. Sometimes you'll see people write rules like "every 30 seconds, check if this motion sensor is active, and then...". I ask my self: why? Hubitat is event-driven (something you can read more about in the general RM docs above if you aren't already familiar), and the best approach here is almost always to subscribe to that sensor's motion attribute, which in RM could be done with a trigger like "XYZ Sensor motion *changes*". (If you do use a Repeat, which can be useful for other things, make sure it is properly formatted and you have a way out, unless you really do want an never-ending loop; in some of these cases, a periodic or time-based trigger may make more sense.)
Finally, we don't have access to these metrics but have been told by staff that CPU, RAM, and disk resources are almost never the problem (see here or search for much more). The speed of Zigbee and Z-Wave networks is more likely to be a limit if you're manipulating lots of devices. Zigbee has group broadcasting that can help in some cases if you use the Hubitat Groups and Scenes app instead of sending the same command a bunch of times in a row to different devices; there isn't anything quite like that for Z-Wave. If you have problems in either case, some people put "Delay" actions in their rule for a second or two between chunks of commands to different devices if they individually address lots of them and notice problems (you may still not). I wouldn't start off worrying about any of this but just keep it in mind for the future. 
Just to add my approach, which hopefully nobody will shoot down in flames. 
I have created naming standards for my RM rules: Variable Set, Sub (Routine), Security, Schedule, Presence, etc. I use these phrases as the first word in my Rule name which has the benefit of grouping similar rules together in the list as well as clarifying what the purpose of the rule is when scanning through the list at a later date.
The 'Sub' classification is for repetitive actions that get used in multiple rules. This makes maintenance of rules easier over time and also introduces consistency. e.g. I send notifications to my and my wife's phone for security and excess temperatures etc. So I have created a global variable %notification% which I populate within each relevant rule then add that to a standard header text in a rule called 'Sub Notification Both Phones'. I then add an action when I want to send a notification 'Run Actions: Sub Notification - Both Phones'. Likewise for my security rules if I want to have certain Hue lights to flash red as a result of a security trigger, I add 'Run Actions: Sub Flash Lights Red'.
Using these Sub (Routines) also allows for Repeats of rules within Repeats, which isn't currently allowed within RM.
Here is an example of my 'Security Panic Button Pressed' rule:
