Not freeing memory is a fairly common approach, in compilers and command line tools as well. If an AST hangs around until the end of the program anyway, why not let the OS take care of blasting it away? free() is expensive after all.
Functions like Type::getInt32() or whatever it's called return the same heap allocated pointer each time so pointer equality can be used for value equality. That's a nice trick that only really works optimally if you leak the pointer, or at least don't free it until very near the end.
I've seen cleaning up memory at the end of a program take 20% of the run time and that was indeed patched to just exit & leak as a result. With a flag to clean up so we could still run valgrind on it usefully.
Yes, any compiler-as-a-library software can't do this.
And compilers-as-libraries are becoming more popular these days since being a library makes it easier to integrate the compiler with tooling, like linters and IDEs / language servers.
You say "before" as if it's a thing of the past :) gcc is still not written as a library. clang became famous partly for providing a C compiler as a library.
Though gcc's case is specifically because of ideology. Even ignoring ideology, there used to be no need to write compilers as libraries, because the only binary that would use such a library was the compiler itself. The only purpose of the compiler was to be invoked from a shell / build script to compile code. That is changing with things like IDEs that need "compiler services" becoming more mainstream, as I said.
