COMBINATORIZE is in no way "the key function"! And it wasn't nativized in order to avoid something usermode could not accomplish. It was nativized with a few other things as an experiment... but the other things were all reverted because the design changed. COMBINATORIZE didn't change much (yet), so it was left using the native version for now. If the usermode code atrophied, that atrophy is hopefully minor.
Ultimately the goal is to nativize everything, but keep the scaffolding which wires everything together communicating in the abstractions of the language... and live-swappable with usermode implementations that do the same thing, just slower. (I've mentioned that I want to put the Rebol and C code for a given combinator in the same file, and have the Rebol code extracted and aggregated from comments in the C at build time. The same would apply to implementation guts like COMBINATORIZE.)
I've already demonstrated a primordial debugger for UPARSE. It depends on being able to programmatically dissect the stack frames of combinators, and that relies on those frames being bona fide FRAME! objects within the language. That's instead of some customized "parse stack" that only applies to parsing (e.g. Red's PARSE) and which would require a whole slew of specialized hooks to expose, and whose optimizations wouldn't speed anything else up.
What is nice is that by doing it my way, cross-cutting enhancements will help everything improve...not just UPARSE. The glue between combinators will still be in terms of usermode-exposable abstractions, so that you can mix and match native combinators and usermode ones. Using such methods does have cost over customized byte-level structures. But it's worth it for the reflection abilities--and of course allowing proof of the ability to express it within the confines of the language if you need to.
So yes: Ren-C is better. 
A large community of extremely patient people... maybe. But large communities of patient people who work for free on weird things are rare.
Large usually correlates with people being invested, and those who invest in things will resist changes that break their systems. To me, Red's thesis--that Rebol2 somehow is an end in and of itself--was disproven long ago. But I'm happy enough to let them continue chasing the three people in that audience.
I don't know what all the remaining massive breaking changes are, but there will be some. I do think "cut down stray bindings so you can assume bindings you encounter are intentional and need not be overridden" was a good example of one that will be rippling for a while.
Right now, I've decided that the third array type of FENCE! opens up a lot of design space that is interesting. That interestingness is scaled up as the viability of binding and dialecting ramps up. It's a tricky change affecting strings, and raising questions with how to have alternative loaders (e.g. if I want to continue pursuing Rebol2 compatibility layers).
So I'm still glad there aren't that many users to deal with disrupting...
Well, if I learn enough to understand Brassica in forming a Rebol version, maybe I can figure out how to contribute to the Haskell implementation as well, and it won't be a net loss of time.