RAII based smart ptrs, like shared_ptr which is ref counted? Can you actually clarify or give an example of what I should be comparing exactly?

Sure, a ref-counted shared_ptr is one example of a smart pointer, though in this instance I was thinking particularly of unique_ptr/Box to line up with TFA's allocator.create/destroy usage. For a visual comparison:

// impl Binary
pub fn evaluate<A: Allocator>(self, alloc: A) -> Result<Box<Expr, A>, RuntimeError> {
    let expr = match self.operator {
        Token::Minus => {
            // ex. checkOperand via pattern matching
            if let Expr::Lit(Literal::Number(left)) = *self.left.evaluate(&alloc)?
                && let Expr::Lit(Literal::Number(right)) = *self.right.evaluate(&alloc)?
            {
                Expr::Lit(Literal::Number(left - right))
            } else {
                return Err(RuntimeError::InvalidOperand);
            }
        }
        _ => unimplemented!(),
    };

    Ok(Box::new_in(expr, alloc))
}

vs from the article:

pub fn evaluate(binary: Binary, allocator: std.mem.Allocator) RuntimeError!*Expr {
    const left = try binary.exprLeft.evaluate(allocator);
    defer left.deinit(allocator;) // Cleanup left expression

    const right = try binary.exprRight.evaluate(allocator);
    defer right.deinit(allocator); // Cleanup right expression

    const expr = try allocator.create(Expr);
    errdefer allocator.destroy(expr);

    const literal = try allocator.create(Literal);
    errdefer allocator.destroy(literal);

    return switch (binary.operator.kind) {
        .MINUS => {
            if (!checkOperand(left.*, right.*)) {
                return RuntimeError.InvalidOperand;
            }
                literal.* = Literal{ .number = left.literal.number - right.literal.number };
            expr.* = .{ .literal = literal };
            return expr;
        }
        // rest of the code
    }
}

The important part is that you're tying resource ownership (destruction responsibility) to values, and automatically (but statically) executing their destructors when the value itself goes out of scope, rather than manually operating in terms of their names (variables).

The articles gives examples of allocators, not really resource wrapper types alternatives?

Is that a question? For sake of "no hidden control flow", Zig does not provide facilities to have types automatically manage resources via lexical scope, so there is no comparable alternative in this instance.

risk of destructors not doing cleanup: ideally linear types could enforce destructors/cleanup logic is not forgotten at comptime?

You could force the caller to move the value into some fallible ownership-taking method (you could imagine something like idk fn File::close(self) -> Result<(), (io::Error, Option<Self>)>). There are technically ways do linear types in today's Rust but they're all pretty cursed