A big challenge lies in designing a system where every user has creation and modification rights, without breaking the system. Systems based on the https://en.wikipedia.org/wiki/Object-capability_model for access control and those that can monitor and set computational resource limits internally can prove very useful there
MOOs (based on LambdaMOO at least) had various write permission levels, including builder (you can make new instances of existing things like rooms or objects and give them descriptions) and programmer (you can make new programs, written in a neat prototype-based language). Wizards could set these bits on other users and ignore permission checks on other users' objects.
One of the weirdest features of the language in retrospect was that iirc you could use object reference literals in your code, since every object instance had an id in the database (eg #1234). This eventually necessitated a special recycler, implemented inside the MOO, to make sure that IDs got reused when objects were deleted.
To add to this, MOO is just an interpreter and very basic network manager. All of the logic for controlling the actual game or environment is inside the database in interpreted MOO code. (You also have control over the network from inside. The server is just handling TCP bookkeeping, basically.) This means, for instance, that you can implement whatever permission system you want. One of the earlier examples is JHCore, which offers different groups of permissions. Really the only server-enforced permission levels are the wizard, which is essentially root, and the programmer. Everything else is up to you.
I'm not positive on the history of the recycler, but I think you have it backwards. It actually exacerbated the problem of using literals in code because you couldn't guarantee that the object you wrote in the code is the same object 20 years later. This created security concerns (imagine you hard-code an object number into your code and now the object is owned by a completely different person who can write their own code on that object. So your code called #123:innocent_function(), which the new object owner has programmed to do something malicious) at worst and broken code at best.
I assume the reasoning was two-fold: First, huge numbers are a pain to type. And in MOO you do end up typing object references a lot. And second, in the early 90's, memory was at a premium. Even a recycled object is using some memory (it still has a space in the object list).
Anyway, if anybody is interested, MOO is still kicking! There's a fork called ToastStunt (https://github.com/lisdude/toaststunt) that offers some slightly more modern conveniences. And the community has, mostly, converged into the ToastStunt Discord channel.
A big challenge lies in designing a system where every user has creation and modification rights, without breaking the system. Systems based on the https://en.wikipedia.org/wiki/Object-capability_model for access control and those that can monitor and set computational resource limits internally can prove very useful there