There's nothing baked in stopping moons from being freed from their planets other than code for that hasn't been written yet. Indeed its the general consensus among the community that creating more addresses by liberating moons would be what is done if the ~4 billion limit were ever reached.
There's ordinary mathematical reasons for the 4 billion limit - it makes the address space 32 bits. I've never met anybody working on Urbit that believes the notion you're putting forth.
Some additional thoughts I have in this direction in no particular order:
Both Holochain and Urbit emphasize composability. One of the main design patterns with Holochain are microservices that you can hook up together to make more complicated apps. This philosophy emanates from the receptor notion in Ceptr (the OS that Holochain is supposed to be distributed data integrity engine for). When I worked on Holochain I spent a lot of time going on about what sort of mathematics you'd need to do this well and without unintended side-effects: namely category theory, as category theory is a mathematical formalization of the notion of composability. Composition is a first-order concept in category theory and the whole point of category theory is to be able to think of things in terms of what they're composed of - this is a large chunk of the content of the Yoneda lemma. I believe that there is a good description of Holochain using category theory in the sense of David Spivak and his collaborators, and more generally that creating an entire operating system made of composable "atoms" like Ceptr would really benefit from that kind of theoretical backbone. I never got to the point of anything really worth sharing, though.
The one project that is going in that direction though is Statebox. They are designing a language for making distributed applications based on new ideas on composable Petri nets and how they can be used to represent symmetric monoidal categories. Work of Abramsky, Coecke, and collaborators has shown that in some sense, symmetric monoidal categories can be thought of as a general model for any kind of distributed computation, including quantum computing. Thus Statebox should be able to talk about things like blockchains, holochains, block lattices, whatever, all in the same categorical language. This will allow apples to apples comparisons, cross-compiling, and lots of other fun stuff. So Statebox is, in my mind, the most mathematically sound language that's in production for building composable systems of microservices. I think it would be really interesting to rewrite Holochain using Statebox.
Urbit attempts to achieve this level of composability by virtue of being written entirely in a purely functional language. Functional programming has many ties to category theory which is why this is the correct strategy, but Urbit actually tries to be as mathematically simple as possible. No category theory is really in sight (ok, some monads are hanging around now) and for the most part, nothing more than high school algebra is needed to understand how Urbit works. The whole system is actually much simpler than the Unix stack, it just doesn't look that way from the outside. Urbit follows the Unix philosophy of simple tools that just do one thing well. You can really start doing some magical things when all those tools are written in a purely functional fashion.
One other project I'm aware of that is trying to do the purely functional distributed apps thing is the Ambients protocol, but sadly I haven't put aside the time yet to learn about it.
This is a question I'm probably better suited to answer than anyone in the world, since I used to work on Holochain in 2018 and I've worked on Urbit since 2019.
They solve a similar set of problems from completely different directions. Chiefly, they are both trying to create infrastructure for running distributed programs that run primarily on the devices of the user in such a way that the user has total control over their own data and not in a horribly inefficient way like blockchain-based dApps.
Urbit has a bottom-up approach while Holochain has a top-down approach. Urbit is about building powerful infrastructure for individual users to manage their own data and, from there, networks of users may be built that can run their own apps and share data amongst themselves however they like. Holochain instead starts by focusing on building networks of users that share data in a prescribed fashion, and how each user manages their own data outside of Holochain is up to them.
I see them as complementary, almost dual to each other. Urbit is about creating infrastructure for individuals that can then form networks, while Holochain is about forming networks that individuals can then join. Urbit starts as close to bare metal as you can get (its a whole operating system, programming language, and assembly-level instruction set) and starts getting thin around userspace, while Holochain lives entirely in userspace. Stack them on top of each other and your entire computer from the GUI all the way down to the processor instruction set is oriented around user data privacy and efficient distributed computing!
In a future where both Urbit and Holochain take off, people could use Urbit to manage their personal data and cryptographic property which would be fed into Holochain apps. There would be a bridge between the Urbit PKI and the Holochain PKI so that your identity in one is linked to your identity in the other.
Both projects aspire to create something like a "universal interface" along the lines of WeChat, except not a dystopian privacy invasion nightmare.
I could write more about this all day. If you have any further questions I'd be happy to answer. I'm mostly excited to have met someone else using Holochain and Urbit in the same sentence.
There's ordinary mathematical reasons for the 4 billion limit - it makes the address space 32 bits. I've never met anybody working on Urbit that believes the notion you're putting forth.