Other than not having to click the child node in the scene tree to edit a variable, I’m not seeing a lot of benefit here.
That’s really the primary benifit. At least that basic benifit is pretty often requested, e.g,: How can I expose child node properties to editor without using "editable children"?
The secondary benifit is that it allows you to define the intended public API of the scene when while authoring it. Often it’s really only acceptable to to edit a handful of properties of the children, but the scene may contain a bunch of internal stuff you shouldn’t touch; hoist allows you to mark these important properties so they’re easy to find.
There are various open proposals to improve this workflow, like this proposal with 115 upvotes: Improve usability of Editable Children · Issue #3248 · godotengine/godot-proposals · GitHub. This proposal is a bit simpler, because it works for entire-nodes, not specific properties.
because you have to type them as Hoist?
That’s just a missunderstanding. The @export var hoist : Hoist is used in the root as a data container, and the target for the editor customization. All other variables would be written or typed as you normally do. I haven’t tested it, but I suspect I even support properties defined via _get_properties_list
The blog post contains more detail than the github readme, if you’re interested.