I think what they were referencing with that is that the kernel hardware interface is unstable, it changes literally every version, which is why you went to upstream it so you don't have to keep it up yourself after that.
As someone with extremely similar experience to thomashabets2 over my life, but less go and more rust, please allow me to compare go's Interfaces to rusts dyn Traits, both of which are implemented pretty much identically under the hood. Rust just doesn't let you construct the data nor vtable part of the interface/trait as nil/null, in any form. Either the interface/traits instances entirely whole or it can't be instanced at all. This is the way to do it, not partially filled in one part (the vtable) and not the other (the data pointer).
A general bevy scripting crate has already been in the works, they were waiting on various things like be y reflect and other such features to be able to work properly and so forth. In other words it's already planned and there's a lot of work being done on it with a whole lot of dependent functionality coming out in every single release.
Indeed, I personally find Rust to be very nice for rapid prototyping, incremental recompilation is usually a second or two even in my giant projects (mold helps on the linking step but that's less of a rust thing anyway), and I'm very curious how cranelift will change things in the future, it would be nice to hot swap function implementations on the fly at least.