Maybe when analysing the stats it helps to distinguish between the intention of the one implementing the transcompiler (e.g. fun, proof-of-concept, research, money, actual need in a project, ...) and the size of the user-base of the transcompiler (in relation to the user-base of the language that is transcompiled to).
Lets say JS's user-base is pretty huge in relation to other languages (which is not an argument for JS). The stats show that a lot of languages transcompile to javascript, so I would indicate a real need for such projects, otherwise there would probably just exist a few as fun/proof-of-concept-projects.
Similar situation for C/C++ (maybe due to lack of high-level features) and Java (due to lack of practical features).
On the other hand: languages that only have a few or no transcompilers that compile to them, does not mean, they are better useable. There could be other things that make writing transcompilers very hard.
Lets say JS's user-base is pretty huge in relation to other languages (which is not an argument for JS). The stats show that a lot of languages transcompile to javascript, so I would indicate a real need for such projects, otherwise there would probably just exist a few as fun/proof-of-concept-projects.
Similar situation for C/C++ (maybe due to lack of high-level features) and Java (due to lack of practical features).
On the other hand: languages that only have a few or no transcompilers that compile to them, does not mean, they are better useable. There could be other things that make writing transcompilers very hard.