With such a complex system like that it would probably be beneficial to actually build the parts you care about and take advantage of libraries handling the querying of Data like ECS and rendering with bevy. Otherwise you'll run into the risk of being limited by the library in one way or another.
Define a bunch of structs that you can use compositionally in bevy's ECS. Create specific systems that react to components being added, removed, or changed. Set conditions like Burnability, Durability, Temperature.. etc. React to those conditions or thresholds being met. Your reaction could even be a component. Damage(5), IgnoreArmorDamage(3), CurrencyUpdate(-5), GiveItem(Item::Sword(Stats {..}))
It basically gives you a foundation that feels like scripting but with the power of compile time safety for virtually everything. You get to "model" the data how you want instead of being limited or overwhelmed. And with ECS it really helps make things feel like Lego blocks that you can easily reuse across the entire project.
I want to say I think they are talking about how great it would be if we could kick JavaScript to the curb and just use WASM for everything. I'm kind of in the same boat.
However, WASM currently doesn't have direct access to things like the DOM, if I recall correctly (this might be the guardrails the OP was referring to?). So, it's only really good for things that are heavy on the CPU. But, as a counterpoint, I don't think it's from a lack of effort from anyone's point. The last thing I remember reading was that there were still a lot of things being worked on to make it happen.
Quick Perplexity search: