They've never said anything about this publicly, but my guess is that they probably considered this once, at least as a supplement to RM. Long before I knew what Hubitat was going to be, I noticed references to something "hubitat" in webCoRE's source code (I can't remember where now...) and didn't think much of it other than wondering what it was. Further, when the platform was brand new to the public (January of 2018) and the similarity of Hubitat's development environment to that of SmartThings was a selling point for a lot of early adopters, staff bragged that it was so similar that someone in the "community" had managed to adapt webCoRE, probably the largest and most complex SmartApp out there. That being basically day one, someone clearly had a leg up--but whether it's because staff was working with the idea or Ady himself was just one of their alpha or beta testers (presumably before going to work full time for ST, which may have also affected the trajectory of this story)--or if it was another intrepid tester entirely--we don't know. All just guesses based on what we can observe...
Further, staff seem quite familiar with how webCoRE works, and that's actually one of the things they've commented on and probably a reason they aren't interested in supporting it: they consider it inefficient in that pistons get stored as JSON and then interpreted via the webCoRE piston app (though with the latest Hubitat fork updates, many people find it to perform well; writing a Groovy app directly would certainly be a more difficult task, even if more efficient).
Rule Machine itself has changed quite a bit on Hubitat. The Rule 4.0 UI we see today allows the creation of automations that more or less is what you could do on webCoRE: an ordered script, actions to perform, possibly conditionally. I know it's hard to remember now, but older versions of Rule Machine just let you choose actions and ran them in a pre-determined order, usually based on the truth value of a "rule," which was then actually a specific concept in RM (a specific combination of conditions evaluated for truth), though other types of rules like "Triggers" (basically what we've got now with more power behind them) also existed.
Oh, and don't forget that CoRE predated webCoRE--and personally, I find the "web" thing to have helped a lot. I could not wrap my head around CoRE. 
Part of the limitations of both RM and CoRE have to do with the UI model that that they're using (more or less the same) and that RM in particular is pushing the boundaries of. Some day, we might get something more flexible here that would allow better UI's--they have conceded that webCoRE's UI would indeed generally be considered better.
Not necessarily: all that needs to happen is that webCoRE would need to adapt to the ST changes. In a recent-ish developer video, they actually very specifically mentioned that webCoRE (the editor portion) could be just a front end that uses ST's new Rules API behind the scenes--so instead of interacting with your ST hub/account via classic Groovy SmartApps (creating pistons that get interpreted by webCoRE on your account), it uses ST's new Rules API instead (creating Rules for you, something new in the "new" ST model). ST even toyed that Rules might be able to run locally some day. How far along the development of this API is, I don't know...and I think it's safe to assume the second thing is still years off if it even happens. 
