This has been answered twice[0] by Russ Cox himself[1]. Some of the reasons were familiarity and the need for segmented stacks, but he goes more on the details in his comments.
It seems to be fast enough for SQL JIT-compiler in PostgreSQL 11+ and shader compilation in the *nix OpenGL stack (mesa), both of which are sort-of-realtime systems.
Can't say anything about shaders but I do know a thing or two about database queries:
1. Queries are often repeated, i.e. most of backend DBs get the same requests over and over again. Even a slow jit compiler is fine here as things just get cached.
2. Queries usually take some time to complete, and this offsets the jit-related latency.
Also, Postgres has a very limited kind of jit compilation, i.e. for expressions only.
Notice that javascript jit compilers usually have a multi-tiered compilation. That's because proper compilation takes time, and sometimes it is more efficient to just do some basic template jiting (or no additional compilation) instead of firing the heavy guns.
That's not a huge problem now that we have GCC and LLVM. The real issue is that the generic-ness, and optimisations, of them makes them pretty damn slow for non-performance critical code.
Writing a basic backend isn't a huge project for a language backed as thoroughly as Go. D, for example, has a non-GCC/LLVM backend which isn't as fast but still does some advanced optimisations (but compiles at warp speed)
