There's nothing "genetic" about how MCMC works. AFAIK, usually with GP, you keep multiple candidates that you evolve together, which is not the case here (it's much closer to metaheuristics such as Simulated Annealing), e.g.:

  let candidate be some random program
  while candidate not correct (per your SMT solver):
      new_candidate = mutate candidate
      let cost be cost of new_candidate
         (varies by different techniques;
          some just measure the number of bits differ
          from expected output of testcases)
      if cost is improved:
         candidate = new_candidate
      else, with some probability (the lower the cost, the higher the prob.):
         candidate = new_candidate

Of course, there's nothing preventing you from using GP instead of MCMC to find programs. The focus of research is on how to mutate (e.g. how do you avoid generating bad candidates based on past experience) and evlaute the cost of a candidate, rather than the methaheuristics itself.

That looks very GP-ish, but - as with all GP - the usefulness of the outputs depends on the sophistication of the cost function.

What does "close" mean here? I don't see that explained.

If you're trying to match outputs, then this is just old-fashioned GP with a minor twist - i.e. including speed in the fitness function, which has the potential to find some novel local maxima, which produce outputs that are close to the target AND very fast.

If you're trying to match instruction sequences - then I don't see the point at all.

GP often fails because it runs out of steam before producing a definitively correct solution.

It's easy to design cost/fitness functions that get close but not close enough, and slightly harder to design functions that solve a non-trivial problem some of the time.

It's incredibly hard to design functions that find an answer reliably without getting lost in the problem space.