EDIT: I have found GPs to be relatively slow-to-very-slow. But very likely that is because of the lack of interest and development compared to NNs
I've dabbled in GP and I really like it but those ASTs can get huge if they're not carefully pruned and might not add to the solution at all.
I don't think it's as simple as putting the length of the AST in the goal function (but it's something interesting to try).
Depending on compile speed vs running speed you might be better off interpreting your ASTs
I don't know what that would do to the learning process -- but at least it would be useful for end results.
I'm generally pretty suspicious of generic algorithms; why take a random walk when you can March along the gradient towards a solution?
It might be interesting to try using GA for neural architecture, though, and gradient descent to train the network... (Though it sounds expensive.)
Because your problem has no smooth/continuous gradient
Because your problem has a giant search space
Because your problem can do with a "close enough" solution
Try gradient descending a symbolic regression and we'll talk
There are two different speeds one could measure in regards to GP's.
The first is the speed at which one evolves solutions. This can, in fact, be frightfully slow and eat up all the hardware you can throw at it (depending on how large your populations are, how fast your fitness function is, etc).
The second is the speed of the evolved solution. This may be slow, but doesn't have to be. In fact, the speed of the solution could be part of what's being evolved. So you could explicitly evolve something fast, if you wanted (or it might just wind up being fast by chance).
One could also take an evolved solution, analyze it, and then optimize it or rewrite it using the insights you got from your analysis. That could be even faster.