I haven't looked at QEMU's TCG much, but I doubt it would be a
good choice for bytecode formats even if you could bash it into doing something useful as
part of a backend. I'd expect it to be optimized for hardware-CPU-alike machine instructions, whereas BEAM is Bogdan's Erlang
Abstract Machine. See
https://blog.erlang.org/a-brief-BEAM-primer/ which points to
https://github.com/erlang/otp/blob/master/lib/compiler/src/g.... If you look into how some of those are implemented, just as one example, the integer arithmetic operations handle automatic promotion to bignums—not something you'd find on a conventional CPU, but not uncommon in HLL bytecode. So you'd still have most of the implementation to do—and if you punt and hardwire all of those to runtime library calls, you're almost back in threaded-code land anyway; you really want to take specialization opportunities etc. into account…
I also don't know of any other HLL JITs that use TCG, which seems like weak evidence that it wouldn't be a win.