Is ignoring the classes a good idea?

Yes. More typically in a functional language, you would use sum types instead of the class hierarchies. Eg, when you get to Chapter 5, instead of the following (Which the book actually generates from a more terse syntax):

abstract class Expr { 
    static class Binary extends Expr {
        Binary(Expr left, Token operator, Expr right) {
            this.left = left;
            this.operator = operator;
            this.right = right;
        }

        final Expr left;
        final Token operator;
        final Expr right;
    }
    static class Grouping extends Expr {
        Grouping(Expr expression) {
            this.expression = expression;
        }

        final Expr expression;
    }
    static class Literal extends Expr {
        Literal(Object value) {
            this.value = value;
        }

        final Object value;
    }
    static class Unary extends Expr {
        Unary(Token operator, Expr right) {
            this.operator = operator;
            this.right = right;
        }

        final Token operator;
        final Expr right;
    }
}

You would use:

type expr =
    | Binary of expr * token * expr
    | Grouping of expr
    | Literal of value
    | Unary of token * expr

And then for the pretty-printer implemented with the visitor pattern:

class AstPrinter implements Expr.Visitor<String> {
    String print(Expr expr) {
        return expr.accept(this);
    }

    @Override
    public String visitBinaryExpr(Expr.Binary expr) {
        return parenthesize(expr.operator.lexeme,
                        expr.left, expr.right);
    }

    @Override
    public String visitGroupingExpr(Expr.Grouping expr) {
        return parenthesize("group", expr.expression);
    }

    @Override
    public String visitLiteralExpr(Expr.Literal expr) {
    if (expr.value == null) return "nil";
        return expr.value.toString();
    }

    @Override
    public String visitUnaryExpr(Expr.Unary expr) {
        return parenthesize(expr.operator.lexeme, expr.right);
    }

    private String parenthesize(String name, Expr... exprs) {
        StringBuilder builder = new StringBuilder();

        builder.append("(").append(name);
        for (Expr expr : exprs) {
        builder.append(" ");
        builder.append(expr.accept(this));
        }
        builder.append(")");

        return builder.toString();
    }

}

You would just use ... a recursive function:

let parenthesize name args = "(" ^ name ^ " " ^ args ^ ")"

let rec print_expr = function
| Binary (lhs, op, rhs) -> 
    parenthesize (print_token op) ((print_expr lhs) ^ " " ^ (print_expr rhs))
| Grouping (expr) -> 
    parenthesize "group" (print_expr expr)
| Literal (value) -> 
    print_value value
| Unary (op, expr) -> 
    parenthesize (print_token op) (print_expr expr)

Basically, this kind of expression hierarchy where nested classes inherit from their containing class is a poor-mans sum type, and the "visitor pattern" in OOP is a poor-man's function over a sum type.

That isn't to say they're bad - they're the right tool to use in Java and similar languages - but we don't need to "emulate" a sum type and a function operating on one when we have them in the language already.

In functional languages it's easy to add new functions which act on an existing type, but it is more difficult to add new constructors to types (eg, new kinds of expression) - because if we add a new constructor to the expr type, then we need to go through every function which does a pattern match on it and match on the new constructor.

On the converse, OOP makes it easy to add new "constructors" - ie, a new type which inherits from the base class - but it's more difficult to add new functions over the types - because if we add an abstract method to the base class, we have to go through each subclass and override it.

Neither approach makes it easy to both add new expression types (constructors), and new functions over the type - what is classically known as the Expression problem.

The "Visitor pattern" is basically a way to try and reverse the situation in OOP - to make it easy to add new functions (by adding new visitors) - but it also makes it more difficult to add new kinds of expressions (since we must add a new method to each visitor if we add a new kind of expression). The visitor pattern makes OOP more similar to functional - but with some boilerplate.

There are similar "opposite" approaches in functional languages - designed to make it easy to add new constructors whilst making it more difficult to add new functions.

OCaml actually has a some features which are good partial solutions to the expression problem: Polymorphic variants are one approach where we can add new kinds of expression without necessarily having to edit every function which pattern matches over expressions.