We actually did run Node-RED on a hub a few years ago, investigating this possibility. The issue we ran into were security problems with the use of Node.JS opening vulnerabilities to the hub. It seems like a nice idea, but for Hubitat (the company), it is a non-starter for this reason. Clearly, there would be a host of other issues that we did not explore having found a show stopper.
When 2.3.9 comes out soon, check out Basic Rules 2.0, which has a flow UI.
Everyone in my home all use iPhones. Likely going to stay that way. I simply found that the native iPhone presence detection was more reliable than I had when using the Hubitat App. (e.g. often when the Hubitat App got a software update automatically installed, presence detection would not work properly unless you opened the app after the update.)
What does that have to do with Node Red? You do not need node red for that.
The Hubitat app has historically been sketchy when it comes to geolocation. It has improved recently, But I still would not rely on it for presence. maybe been bit too many times by it. But I'm happy with using geofency. It has been rock solid.
In the end, as @bravenel stated, there were issues with node red that (at least in Hubitat's view) which made it a non-starter to be natively included with the hub. I know there are those who do use and rely on it, and I have even thought of playing with it myself, but it appears (for the foreseeable future anyway) to be relegated to a third party or community integration status.
Above quote is what I wrote about stopping using Hubitat App as part of the logic. Made NO mention of actually doing geolocation in Node Red.
Above indicates that I now rely on the native apple iPhone geolocation system (no 3rd party apps etc).
[/end off-topic post]
For what it's worth, now that the prospect of this has been somewhat squashed....
Personally I would have said I thought it unlikely this request got up given what I perceived to be the elevated resource requirements for NR, but am happy to see Hubitat staff at least considered it, including the fact that this would have meant they considered the prospect of having Node RED as an automation option natively hosted on a HE hub. That, I think, at least, shows a willingness to look outside of solutions developed in-house, which is encouraging. It feels like if there are reasons to reject NR on the current platform, could there be options opened up with a change in the underying platform that could allow this to happen? 
I was going to comment in the same direction 
@bravenel What if instead of running it natively you could run it in a JVM using a technology mentioned in the original post (or some other for that matter)?
Maybe a container, like Kubernetes, Docker, etc?
Would that help with the security issues?
Not so much, CPU usage is close to zero, memory usage in my instance is currently 97 MB, which is not very low, but it certainly wouldn't be a problem for a C8-Pro, (mine right now has 1556.62 MB free), and I doubt it would be a problem even for a C7. Unless you're doing something crazy, in which case you should be running it outside the hub anyway 
In my "perfect" world, that is exactly what the hub would allow - running of some limited set of containers.
I completely understand that is NOT the direction they are going, and am OK with that. But if they were going to allow additional capability, that is the only reasonable path in my opinion.
I don't know the answer to this. We took the straight forward approach of wanting to run Node-RED as is, which meant running an instance of Node.JS. Certainly there could be other ways to do it that we did not explore. Believe it or not, there have been things more important for our customers to put our resources on. Perhaps we will explore this again in the future.
Thanks for keeping this as a possibility for the future!
Download the Hubitat app
