Rebol had a lot of disparate elements, and people latched onto different ones... based on which parts they wanted to believe were the most important.
To some people, the lack of dependencies and not needing an install program was key.
To some people, it was very important that Rebol was cross-platform so they could deploy the same programs to customers on Windows/Linux/Mac.
To some people, they couldn't write a GUI on modern systems with other tools to save their life. So having a way to get a button on the screen with minimal code and not having to figure out what graphics libraries to pick for their language was key. (These are people who could have used Visual Basic, but felt it was just getting too bloated and unpredictable, and found they liked other aspects of Rebol better.)
To some people--myself included--the notion of having a language you could really bend to whatever task you were doing via dialecting was the main draw.
Anyway: point being there are a lot of ideas in it, and wound up with a lot of wishful thinking and projection being put on an artifact that was ultimately too simple and under-designed to live up to the hype. Carl called it his "grand experiment"...and I think of the usage of "experiment" in the sense of "this might not work". Some things have worked out better than one would expect, and others have shown to be fairly intractable in the medium.
Data representation is tough, because the structure of data is often connected in weird ways...which you need graph databases to do correctly. Trying to represent graph structures in text is a very narrow and limited idea.
I think that JSON took most of the low-hanging fruit of what Rebol's base format could have offered in data exchange, and YAML has actually stepped in for a lot of places where JSON isn't a fit and shown to be better still.
The fact that Rebol did not set up a clear way to lexically exchange objects left it in a tough situation where I think it often works out to be inferior to JSON for most tasks...despite having some superficial niceties of knowing how to--say--exchange dates. (More often than not, people wind up needing ISO 8601 dates anyway, which shows that Rebol's peculiarities aren't always all they're cracked up to be when working in a world that Rebol is not a standard.)
Carl seems to have wanted to rethink the object issue--to the point of sacrificing braced strings--see his ASON:
Carl's New Projects (?) AltScript, AltOS
(I considered this, but ultimately decided I thought the braced strings were too foundational to what makes Rebol good...so we'll have to address that weakness some other way.)
As a thought experiment it would be great to see if Rebol-to-Rebol data exchanges could have a start-to-finish story where the whole experience is better than JSON, without this:
I've written some thoughts here and there about directions I think things might be able to go in the representation:
BLOCK! and OBJECT! Parity in Pathing/Picking
