You already quoted most of the explanation (btw. where's that cited from?). The TS version in ANTLR4 (which is not a fork btw.) is type definitions on top of the JS runtime. Additionally, the generator template and the test infrastructure have been updated for the generated TS code (which is in fact pure TS).
The antlr4ts fork is a special version, not compatible with ANTLR4, as it contains some special optimisations, which make it sometimes faster, sometimes slower than the original code. I used it for years but its development has been stopped (it's still an alpha version and effectively abandoned) and hence it is missing new features like case insensitive rules.
For these reasons I started a new TS runtime (my second runtime, after C++) and tried WebAssembly to get the speed of C++ (https://github.com/mike-lischke/antlr4wasm
). This approach, however, is problematic as it is slower than the JS runtime and has lots of memory and exception handling problems. Measuring speed for that new runtime showed me how fast the JS runtime actually is. I was pretty surprised. That's why I decided to create the new TS runtime using the existing JS runtime as start (and stop wasting my time with the wasm attempt).
So, considering all this it should be easy to decide what to use. If you want to stay on the safe side and are not affected by all the limitations of the current "TS" runtime, then go with the main ANTLR4 version. In all other cases I recommend considering my new TS runtime.