No--you probably want to turn the lights on with motion, then turn them off after a delay after inactivity is reported. It sounds like you're turning them on with motion, then blindly turning them off after a delay regardless of whether there is still motion. If you really want to use Rule Machine for this, the docs contain an example of what you'd want to do here.
"Wait" and "Delay" are different--I'm sure you were just using generic terminology, but these are specific in RM and it matters because the answer is different. Delays will get piled up unless you set the "cancel?" flag on them and run a "Cancel Delayed Actions" action where appropriate (in the motion lighting example above you can see how this could be done). "Wait" actions, however, do get cancelled every time a trigger happens.
Well, Motion Lighting (and Simple Lighting) are a lot easier to set up since they're basically templates you can fill your devices and other preferences into, but you have to start from the beginning creating the automation yourself with Rule Machine. It's also therefore more likely for you to make a mistake. (There have been mistakes on the other side, too: bugs Motion Lighting or Simple Lighting, but they have been fixed quickly, and there have also been bugs in RM, also fixed quickly, so I don't see a particular advantage to one over the other just for this reason.) They are also likely a bit smaller code-wise and probably take a bit fewer resources for the hub to load when "triggered" (when scheduled or subscribed events happen), but that's probably a small enough difference to not be noticeable.
The real advantage to RM, in my opinion, is that it's more customizable. Motion Lighting has a lot of options (and they've listened to feedback and added more since it was introduced), but Rule Machine gives you the ultimate flexibility to set the automation up exactly how you want it. The tradeoff is that it's more difficult to set up.
