i'm glad to hear you find it appealing! i'll explain some of my thinking on these issues,
some of which is specific to my own eccentric objectives (nobody designs computers to last decades) and some of which is more generally applicable

screw terminals or post terminals are a good idea if you're going to have charging
and want longevity. but charging implies batteries.
and batteries themselves induce lots of failures; they typically
have a design lifetime of two years, more than an order of magnitude too low
for the zorzpad. by itself that's not a fatal flaw, because you could replace
them, but it becomes fatal in combination with either of the two supplementary
flaws:

1. battery shelf life is limited to about 10 years, except for lithium thionyl chloride and so-called 'thermal batteries' that use a molten-salt electrolyte (kept frozen during storage). consequently, if your computer needs batteries,
after 10 years you're dependent on access to not just a market but a full-fledged industrial economy to keep your computer running. a friend of mine in rural romania
has been trying to build a usable
lead-acid battery from scratch to provide energy storage for his solar panels, and it's motherfucking difficult without that supply chain

2. batteries have a lot of failure modes that destroy the devices they power. overheating, swelling, leaking corrosive electrolytes, and too much voltage are four of them. if these failure modes were very rare (like once in 100 battery-years) that might be okay, but they aren't

for me these are fatal flaws, but for others they may not be. if you can afford batteries, you can run for one hell of a long time on a single 18650 lipo on a milliwatt. a coin cell can deliver a milliwatt for a month

as for uxn, uxn is the first attempt at frugal "write once, run anywhere" that's good enough to criticize. everyone should read devine's talk about its aspirations (https://100r.co/site/weathering_software_winter.html)

however, uxn is not frugal with cpu, or fast, nor is it good for
programmer productivity, and it’s not all that simple. It’s designed
for interpretation, which inherently means you’re throwing away 90% or
95% of even a single-threaded cpu, and it’s not designed as a
compilation target, which means that you’re stuck programming at the
assembly-language level. This is pretty fucking fun, but that’s
because it makes easy things hard, not hard things easy; the offgrid
notes lionize oulipo (https://100r.co/site/working_offgrid_efficiently.html)

as a result of the efficiency problems, the platforms with complete uxn
implementations (see https://github.com/hundredrabbits/awesome-uxn#emulators)
are the luxurious ones: microsoft windows, linux, amigaos, the essence
operating system, anything that can run sdl or lua and love2d, gameboy
advance, nintendo 64, nintendo ds, playdate, and the nook ereader: all
32-bit or 64-bit platforms with ram of 4 mebibytes or more, except
that the gba only has 384 kibibytes, and there were amigas with as
little as 512k (though i don’t know if they can run uxn). more
limited machines like the gameboy, ms-dos, and the zx spectrum do not
have complete uxn implementations

(384k is the same amount of ram as the apollo3, so it's probably feasible, as you say)

the uxn machine code is basically forth. forth is pretty aesthetically appealing to me, and i've gotten to the point where forth code is almost as easy for me to write as c code (though i have to look things up in the manual more often and have more bugs). however, it's much, much harder for me to read forth than it is to read c. it's harder for me to read forth code than to read assembly for any of 8086, arm, risc-v, i386, or amd64. possibly i just haven't written enough forth to have the enlightenment experience yet, but currently my hypothesis is that forth is just hard to read and that's it, and that the really great thing about forth is not actually the language but the interactive development experience

the varvara display model is not a good fit for the memory-in-pixel displays, which only have one bit per pixel, while varvara requires two.
also, evaluating things 60 times a second is not a good fit for low-power systems of any kind.
and i'm not sure how well the existing varvara applications will work at 400×240 or tolerate a requirement
to use fonts many pixels tall in order to be readable

(a lot of the above notes are from xpasm.md in http://canonical.org/~kragen/sw/pavnotes2.git/ if you're interested in the context)

as for tools for software development, program launching, editing text, editing fonts, editing other graphics, and sequencing music, i'm confident i can write those myself if i have to. i've written a compiler in a subset of scheme that compiles itself, a compiler in a forth-like language that compiles itself, various toy text editors, various virtual machines in under 150 lines of code, and various pieces of music synthesis software, and i've designed a few fonts of my own (though not using software i wrote)

maybe i should set up a patreon for this or something, maybe people would be interested in supporting the project