There aren't really unknown implications, but some are subtle and learning is required. The hub is an event driven, multi-CPU, multi-threaded computing engine.
Apps have state variables (certainly Rules have a lot of state variables). Those state variables are stored in the database, so they persist across instantiations of the app. Every time an app exits from execution the system writes the state to the database, and every time app execution begins its state is loaded from the database. This writing and loading of state takes some amount of time -- not a lot and not zero. It can't be predicted exactly how much time it takes, but evidently in some cases longer than 4 msec.
There is only a single copy of state for all instances of the same app. So, having multiple instances executing at the same time can be problematic. The most typical problem comes from delays or repeats embedded in an IF-THEN-ELSE of a rule. Because IF-THEN-ELSE can be nested, the current point in an IF-THEN-ELSE is recorded in state. So with a delay embedded, the rule will exit for the delay, and if another instance comes along into the IF-THEN-ELSE, there is intrinsic ambiguity as to which instance is running, and the state can be put into a wrong condition by the second instance.
These multiple instance problems can be avoided for the most part in RM by using Required Expression for PB true, setting it false as the first action and setting it to true as the last action.
Rules with multiple devices as triggers pose the problem that they can be triggered multiple times, possibly resulting in multiple simultaneous instances of the rule (although not necessarily, depending on timing of the events). In the case where the rule is simple, this won't cause any problem. For example turning on a device multiple times is generally harmless. But some thought about what can happen is required -- just as it would be with assembly language or any programming language.
Some apps are "Single Threaded", a setting that causes the underlying system to only allow a single instance to be running at any given instant in time (but not preventing multiple instances per se). Apps like Room Lights are Single Threaded. Rule Machine is not. The main virtue of Single Threaded execution is that we can be fairly certain there won't be simultaneous attempts to read or write state for the app. Even with Single Threaded execution, Room Lights still has to contend with multiple device events and how that might affect the state and actions the app should take.
None of the above is really 'black box'. This is all pretty normal stuff for software in a multi-CPU multi-threaded environment. Dealing with the implications of such an environment is similar whenever coding in assembly language, Groovy or Rule Machine.
