Triviality is in the eye of the beholder, but I consider this the correct choice for the application. I've already registered my one objection, but don't mind expanding on why I think this is a good idea.
Lil is designed for an interesting, if a bit retro, reboot of HyperCard. The fantastic thing about HyperCard was the ability for a user to just... change stuff.
In a HyperCard system, users become developers whenever they want to.
They're going to make mistakes. A lot of mistakes. Mistakes you and I, as developers, won't understand.
What should the runtime do? Not break. "Attempt to index a nil value" is a cruel thing to tell someone who is trying to create a dictionary.
What this does: "oh, you're trying to index this value? Ok, it's an empty dictionary now". "Oh, you're trying to sort it into a drop-down list? Empty string, nothing happens".
HyperCard scale isn't dozens of developers working on a cadence, with branches and merge reviews. HyperCard scale is someone making something really cool, and dozens, maybe hundreds, of personalizations. Some shared, some not.
The distinction between, say, adding photos to a gallery, and adding a photo editor to the stack, is not sharp in HyperCard.
I'm very pleased to see this project, although I think the retro aesthetic might be self-limiting at some point. The loss of HyperCard was a real one, we're suffering from it to this day.
This makes me think of the many programmers who started with BASIC on the early 6502/Z80 systems. BASIC of that era was a truly atrocious language (it got better later) but many of those people went on to learn better tools and make the computing world we know today. The original primitive tool served its purpose, which was largely to get people excited about the possibility of shaping their own experience instead of just consuming prepackaged applications. AFAICT Lil is a far better language than early BASIC, and that's enough.
Unfortunately, the fact that a system is not designed to be used at a nontrivial scale is no guarantee that it won't be used that way. For instance, there are a lot of Excel worksheets doing things I am sure the designers of Excel never expected Excel to have to do.
What's the solution to this problem? On one extreme end you can clearly state its intended use in documentation and allow undefined behavior, and on the other end you prevent the user from using the tool in any undefined way.
I'm generally positive about restricting undefined behavior at a lower level (syntax, undefined field accesses, etc), but at a higher level (writing large scale applications, using it outside of intended domains, etc) it's not very clear how and even if you should restrict unintended usage.
The more room you have for "undefined behavior" at a higher level, the more people can explore using a tool in various ways you never thought about. This can in turn be valuable feedback on possible directions to expand your tool in.
Noooooo, this is a terrible idea if you want this to be used at any non-trivial scale