> Second, that additions and modifications to Org-mode tend to use Emacs' text juggling here and there instead of a higher-level Org API and string functions
I was shocked when I started looking into Org's API and found everything is done via parsing. There's virtually no tree/graph type API.
That's done throughout all Emacs addons: basically its text-modification API seems to have been constructed backwards from what's available to the user and the UI, instead of the other way around, and depends a lot on the cursor position. Even the more-or-less popular string library ‘s’ is a third-party addon. So Org pretty much went on with the common practice here.
With the volume of addon development that Emacs managed to get, it's a quite solid case of ‘worse is better, but you're now stuck with the worse for your life’.
There's org-element, if you want to parse/generate org-mode, but it's true that many packages just operate on the text.
org-element doesn't go far enough. Say I wanted to traverse my document in depth first order. Or in breadth first order. How do I do it? org-element does not let me choose.
I say this as there is another well known node based editor out there: Leo. Nonprogrammers manipulate their documents trivially with Python code in a way that's a huge pain in Org mode even for seasoned developers.
somebody should write an org-mode-like clone in TeXmacs, taking advantage of the structured editing features there. Is powerful enough to play tetris (https://github.com/mgubi/tm-tetris) , sure you can do org-mode kind stuff there too.
Emacs' flirt with Guile promised to mend one of those ailments—especially considering how on my oldish machine Emacs' GC hiccups every few seconds when just scrolling through an outline, and Emacs internals don't seem to get lots of low-level development these days (understandably, but still). Alas, that hope now has a grave of its own.