Yeah you're totally correct that ultimately the specific implementation details are what matters for performance. You could easily take either system and make it terribly slow, or more than fast enough. That's why I was somewhat deliberately vague about performance claims, it's really just a vibe-based thing.

Basically in my experience when you actually build a behavior tree as a tree, you get a pretty significant node count once you try to do anything remotely complex, just due to the way that behavior trees implement both control flow and actions as a (usually) static tree. In large AAA games this can really quickly turn into a situation where you have tens of thousands of nodes in a single behavior tree, which you then need to deal with somewhat efficiently. This affects not only the runtime, but the editor tooling as well, since these are often authored as visual noodle graphs.

You could totally lower the tree to some kind of bytecode, or optimized representation, but something I like about the approach here is that you kinda just don't need to do that. It's naturally resistant to the kind of node explosion you get with static trees because the decision logic is contained within nodes as Lua script (or C++ code), rather than built into the tree structure itself.

It's not a strongly justified position, I just think these kinds of structural decisions have an oversized impact on the amount and kind of optimization work you need to do down the line.

(Author here, if it wasn't clear)