That, in and of itself, wouldn’t make a difference to how RTF files are saved, or stuff within them—this is probably true. But if the point that was being made is an observation on development focus then I would agree with it. Nisus focusses all of their effort on making the editor component as powerful as possible—because that’s what they are doing; with the exception of some dialogue boxes, the whole program is in the document window. Scrivener on the other hand puts most of its design effort into the project infrastructure, and the architecture of using large-scale file repositories to construct documents through a compiler. The text editor itself isn’t a recipient of a decade or more of sustained coding to that same degree.
That would be nice. 
I wouldn’t cross my fingers though. They long ago decided to reinvent the wheel with Pages—I doubt it shares any common code with the text editor the rest of the world has access to, other than the most utterly fundamental components of font rendering and such. I.e. to bring anything they develop for Pages into the broader-use development toolkit would be to write a new implementation of it from scratch.
They haven’t historically paid much attention to it. We’re in a very small class of users of that text editor that demand a lot from it. Most software developers using the text engine find it does well more than they need to format text messages, to-do list notes, etc.
It’s an interesting approach for sure. I had some thoughts on a system like that way back when (you’ll need to scroll down almost to the very bottom of this rather long dog’s breakfast of post)—though chiefly I was interested in making double-spacing something useful in a digital context—and more as an intuitive visualisation in reaction to edits made to the text, as automatic annotation rather than modifying the original.
Toward a model more like what I think you’re talking about, I tried to adopt something similar with Curio initially, and then Scapple. I would take a passage of text and import it as paragraphs=notes, then around that centre column of original text, build a cloud of annotation and marking, using the tools provided by these programs. Curio in particular is well-suited to this task, with its freeform drawing tools and other plethora of visualisation and its overall “art board” approach.
That’s all Mac-based though, which I suppose for some might defeat the purpose. I did try using a tablet for a while, as a proofing tool. I never did get along with them for writing, but they do have a certain charm for read-only proofing. Back when I was interested in making it work though, all of the tools were unnecessary clumsy. I might give it a shot some day. I’m a big proponent separating proofing from editing, and that is how I work on a Mac, but to a degree you can say that working on a Mac is a form of editing, even if you’re proofing on a PDF—it’s an immanently editable environment, whereas for me, the iPad has a huge barrier of friction toward actual editing; an asset in this case.