webCore on ST runs in the cloud, but on HE it runs local. Default is to use the cloud for editing rules, but you can set up a local device (many people use an RPi).
Edit: See that others have responded in kind, and you have already taken note. Cheers.
This is a 100% subjective observation as me a 41 year old D- high school graduate left Vera solely because creating the automations (first with PLEG then with Reactor) was extremely too complicated.
It's very disingenuous for you (after only 2 weeks) to claim it's too complicated when what you are using to compare it to you've probably spent a year or more learning it.
Here is my "Thermostat Rule" which took me less than 5 minutes to create. Just one single page that fits into one single screenshot.
Iām not sure there is a distinction, but the globals are for use with RM.
You can, however, create a connector and use the global outside of HE. I actually use a change to RM global variable to trigger a webcore piston.
I haven't tried it, but there is anther Node-esq project for HE being built and usable now that allows you to use Typescript or JS to build rules with HE:
It's no secret that the RM UI leaves something to be desired, but to be fair to the Hubitat devs, they are working with a UI framework that they more or less didn't design (it's a near clone of the SmartThings SmartApp UI model, which was designed to show UIs on mobile devices since that is the only way to do this on that platform). RM 4 is quite a bit more powerful than earlier versions of RM, though some things may require a few more clicks than they did before. The tradeoff is great power. Staff have mentioned that they are not totally opposed to a UI framework revamp, but this is unlikely to be a priority for them at the moment, and even then, RM would likely not be one of the first beneficiaries (though it does probably push the limits of this UI framework the most).
I suspect that some of the comments on RM result from simply not being used to it. I don't doubt that Reactor on Vera is great, but honestly, from watching the video and looking at the screenshots for a few minutes, I seem about as confused as some people say they are with RM inititally. 
(I can say that I tried Vera back when PLEG was the closest alternative suggested for this purpose, and I left, though by no means for just for that reason.) There are lots of docs and examples (examples, examples, examples forum tag) for RM, and looking at some of those is likely to be helpful. Giving it time to get used to many also help.
PS - I'm not sure all of what that thermostat "rule" does, but Thermostat Manager built-in to Hubitat may help. Unlike a lot of other platforms I've played with, Hubitat has a lot of pre-built "apps"/automation templates to handle common tasks, reducing the need to write custom logic for everything in the first place.
PPS:
There are actually delays and waits, which behave in slightly different manners, but depending on what you want, either can be used to create this effect. The suggestions above are one way but may require two rules (which there is nothing wrong with). Within a single rule, something like this will do something if the door stays open for 15 minutes, for example:
Trigger: Door changed
Actions:
IF (Door open) THEN
Delay 0:15:00 (cancelable)
// Do things
ELSE
Cancel Delayed Actions
END-IF
Alternatively:
Trigger: Door open
Actions:
Wait for event: Door closed --> timeout 0:15:00
IF (Door open) THEN
// Do things
END-IF
The biggest difference (besides the fact that "Wait"s are generally intended to respond to events or conditions and not just durations) is that delays must be explicitly cancelled, whereas in-progress Waits are cancelled any time a trigger matches (and in any case, when a trigger matches, the rule begins running from the top).
These are just a couple other ways you could approach the same problem.
PPPS - All of your IF THENs appear to be missing END-IFs. Harmless if it's the last thing but would start to matter if you nest or have additional actions afterwards.
You're not alone. I find RM to be a weak spot in the Hubitat platform, and not only for the reasons you stated. I eventually decided to try out Node RED (somewhat begrudgingly, due to it being off-hub). I'm loving NR now, and I've moved just about all my rules over to it. I do wish I didn't need to run another device (RPI 4) for the purpose, but I'm happy with the results and performance.
I am using WebCoRe for ST and have just (for reasons which should be obvious) purchased an HE. It's on its way. I was reading through some WebCoRe commentary from 2018 and getting it to run on HE did not seem all that trivial. Is there easier integration now?
Mostly just copy the piston from the ST instance to the HE instance. The only thing I had to change in my pistons was for my buttons, as they work a bit different in HE than ST.
You can load Webcore using the package manager. So that is easy as well.
First of all, welcome to the HE community.
Super easy.
The first thing I would do is install the app (not built in) Hubitat Package Manager.
This is a custom app developed by a HE user which makes it easy to install custom apps and drivers built by users of HE.
You can the install webCoRE through HPM.
With HPM you can then receive notifications of any updates to these apps and drivers that you install or even update them automatically should you wish.
Once WC is installed you just use it as you did on ST.
Instead of using the WC server you can install it locally on an RPi or something similar which keeps defining/editing/deleting pistons all local.
All pistons run locally on your HE hub with, for me anyway, no issues.
Well that certainly is appealing. It's pretty cool that the pistons run locally on the hub, too. Defining, editing, deleting pistons doesn't need to be local for me. If my Internet connection goes down I can forego administration as long as they still work.
I'm a recovering Wink user who escaped to ST and then realized I had exchanged ridiculously horrible for just very sucky, so I am looking forward to HE. I don't suppose there's a device migration tool by any chance?
If you mean from ST to HE, I'm afraid not.
What you can do though is leave your devices on ST initially or as long as you want and then use an app called HubConnect to link your HE and ST hubs together.
Make HE the server and ST the client.
Copy/sync your ST devices on to HE and run all automations on HE.
This way everything runs locally (apart from cloud based integrations like Alexa and Google).
You can then, if you wish, gradually migrate your devices to HE and then when complete, turn off your ST hub.
Some people leave it on though as there are some things that do run better on ST than HE.
I for one love rule machine. I've tried a lot of other simple to use polished UIs and still prefer RM.
It may be a bit confusing at first, but I find it very easy because it's just basic logic.
Also I find it easier to make multiple rules instead of one big rule.
Example water heater control. One Main rule, 4 Boolean Control rules.
Here's an example of the private Boolean to turn it on Monday through Friday. Ignore the times, I get up at 4:00AM during the week, and the dirty kids need to shower early in the afternoon. 
Yup it does... even Bruce said he wished it could be better as the interface isn't user friendly.
For what it's worth I initially found RM really hard to use (and to be honest I occasionally still get frustrated by the awkwardness) but honestly once you have figured the UI out you can be pretty quick.
I still wish there was a way to just sort of 'type in' what you wanted (e.g. an alternate input method) but it works so well (once you get it entered) RM is well worth it.
I agree with overall sentiment - Rule Machine is powerful, but it would be nice if the interface was easier to use. I don't configure new rule often, so each time I come back to it, I feel like I have to relearn things.
Yes there is some subjectivity to my opinion, that's why its an opinion - that said with PLEG I 100% agree. PLEG has to be the worst automation system ever conceived and I tossed it after about 4 hours of trying to understand the gibberish manual and obtuse UI.
It's not at all, my criticism is entirely valid - it's a UX nightmare! I work for a software company (the leader in our field according to Gartner) and if our UI team came up with that kind of navigation complexity, our customers would get out the pitch-forks and flaming torches and march on our HQ!
Reactor is clean, simple, yet powerful, you can read it at a glance and know exactly what is going on. Yes, there is a learning curve, but it's not a steep one. RM isn't exactly "hard" either, however, its UI too complicated which makes life much harder than it needs to be.
It took me a little while to figure out RM, but I also find it difficult to edit existing rules. 50% of the time, I have to rewrite the rule from scratch because I messed it up or can't figure out how to edit it correctly. If Hubitat had an rules interface like Node-Red, that would be wonderful!
The final logical output is great - my complaint is the UI makes building logic harder than it should be.
Download the Hubitat app
