I can very much follow your thinking, and also think it’s important to get to the core of the intent of why a lot of people ask for an onboard solution regarding TextBundle - and to read this in context.
This is a paradigmatic case where it’s more important to ‘read’ the intent, use scenarios and existing use constellations centered around DT than to get bogged down in technical questions or overly precise technical descriptions (especially when dealing with non-tech-centric users/customers) and translating everything into a purely technical import/export problem and loading this off to peripheral – script-dependent – solutions.
While nobody questions that it’s possible – and sometimes helpful – to import and export TextBundle through technical additions (scripting), this misses everything about a) the relevance/motivation of the request and b) the real reason TextBundle exists, and the realities of people using TextBundle.
TextBundle really is an exchange format. The impressive list provided in another thread by @jonmoore illustrates this: you find many venerable Mac apps there – and while none uses TextBundle as their basic work format, they nevertheless all provide an inbuilt(!) way to read it, honor/preserve the integrity of the format and – in some rare cases – even edit it. These cornerstone apps – or: their makers– recognize its critical purpose in exchange with other – also important – apps.
So while one can describe the format as ‘niche’ (maybe because no app uses it as ‘base format’…? 
), one can also see it as a neuralgic exchange format for media-enriched documents that has arisen from a specific use/problem situation re. interoperability between different apps in the speheres of markdown, mindmaps, and scriptwriting.
TextBundle exists to ensure data integrity in situations where the relevant unit is a rich document – text with associated images/media attachments, and not just the sum of its parts. Its official description can be paraphrased: ‘Primarily designed for the exchange of plain text files, such as Markdown or Fountain or mindmaps, in need of structured association of images or other attachments, between sandboxed applications.’
In the particular case of Markdown, which matters greatly for people wanting its benefits while working with media-rich texts, TextBundle incorporates images and media in a way that is portable and less prone to errors than using links to external folders. Everyone trying to use media-rich text documents within the Markdown universe knows it’s otherwise a PITA to deal with text-image combinations, especially across multiple apps or storage locations – even more when there is any kind of “roundtripping” such documents btw apps.
TextBundle serves structurally similar functions to OPML, or can maybe even more in case compared to the (proprietary) docx format or rtfd, as these latter two also maintain images and media attachments with their text bodies, preserving structural integrity.
While technically there can be scripted ways to import and export into/out of DT (porting means a process of friction, one should remember, though…), this doesn’t do justice to the intent of the format (an exchange format preserving a kind of document integrity and – more or less frictionless – “ease of use”), or the requests formulated here – whether in discussions around [photo-centered journaling](https://discourse.devontechnologies.com/t/advise-on-a-photo-centered-journal/), or at [multiple other places voiced in the forum](Search results for 'textbundle' - DEVONtechnologies Community ).
Scripted import/export simply breaks up (and on export reassembles) a data structure that is intended to be integral from the point of view of a non-technically inclined user.
A second perspective underlines the validity of the original requests and is crucial in understanding the real motivation of the requests: they come from people interested in “comfortably” writing and editing media-rich texts – things like visual journaling, or media-rich note-taking. While DT can be used for note-taking/journaling, this is, as we know, not its main intended or even recommended use. So, as documented in the forums, non-technically oriented writers/note-takers will – in the main – never use DT as their mainstay note-taker/journal editor. That is exactly in line with DT being primarily architectured, geared, and labelled(!) for intelligent data and file management - and not for editing/collating media rich documents. DT’s mainstay is to serve as a centralized location and organizational environment for all one’s documents, or interrelating them intelligently – without losing underlying document structures*.
For that very reason, the motif of the customer requests is – in the main – not to hand over or export a set of data structures from/to TextBundle in a technical way (though this is possibly helpful in some scenarios). Rather, it’s to leverage TextBundle as an easy-to-handle(!) transmission format that guarantees data-set integrity ‘in travel’ in cases around structured datasets (documents).
One can turn down that request, of course, and there will be some good reasons (missing resources; other priorities). But it doesn’t help the cause or increasing understanding of needs/uses, to always “silently” re-interpret (re-frame) the issues as a purely technical matter of ‘getting TextBundle data’ in and out of DT ‘in some way’… without acknowledging what really is on the line, and listening to use-cases and motivations of non-tech users.
It’s also important to see/acknowledge that DT is often and for a whole set of users not the ‘pivot for everything one does’ (even if some knowledgeable people here can use it like that), but really a hub for working with different and heterogenous documents, document formats, and document workflows which might involve DT – but do not make it the center of every document interaction. (With ‘document’ per se being carriers of data structure and integrity)
Embracing this legitimate perspective/framing – in which many ‘ordinary users’ would describe the issue and needs (see requests here in the forum) –, and opening up DT for TextBundle could also bring big intrinsic benefit to DT: it would align with, and indeed strengthen, its self-ascribed role as document manager and hub to interrelate and work with heterogeneous document formats, serving as a grand mediator and data collection and organization powerhouse.