I don't understand what the issue is: a transpiler is a compiler that outputs in a language that human programmers use.
It's good to be aware of that from an engineering standpoint, because the host language will have significantly different limitations, interoperability and ecosystem, compared to regular binary or some VM byte-code.
Also, I believe that they are meaningfully different in terms of compiler architecture. Outputting an assembly-like is quite different from generating an AST of a high-level programming language. Yes of course it's fuzzy because some compilers use intermediate representations that in some cases are fairly high-level, but still they are not meant for human use and there are many practical differences.
It's a clearly delineated concept, why not have a word for it.
GCC outputs textual GNU assembly language, in which I have written, for example, a web server, a Tetris game, a Forth interpreter, and an interpreter for an object-oriented language with pattern-matching. Perhaps you are under the illusion that I am not a human programmer because this is some kind of superhuman feat, but to me it seems easier than programming in high-level languages. It just takes longer. I think that's a common experience.
Historically speaking, almost all video games and operating systems were written in assembly languages similar to this until the 80s.
Of course I'm aware of this, I've written some assembly too, most definitions are leaky. And if GNU assembly had wide adoption among programmers right now and an ecosystem around it, then some people might also call GCC a transpiler (in that specific mode, which is not the default), if they care about the fact that it outputs in a language that they may read or write by hand comfortably.
They also called C a high-level language at that time. There was also more emphasis on the distinction between assemblers and compilers. Indeed, they may have used the word compiler more in the sense we use transpiler now, I'm sure people were also saying that it was just a fancy assembler. Terminology shifts.
I think what happened was that, when writing in assembly language was a common thing to do, programmers had a clearer idea of what a compiler did, so they knew better than to say "transpiler".
The issue is confused because of Javascript and the trend to consider Javascript "bytecode for the web" because it is primarily "compiled" from other languages, rather than being considered a language in its own right.
I've gotten into arguments with people who refuse to accept that there is any difference worth considering between javascript and bytecode or assembly. From that perspective, the difference between a "transpiler" and a "compiler" is just aesthetics.
I do think you are right, the concept is not common outside of the JS ecosystem to be fair. Indeed, it probably wouldn't make much sense to transpile in the first place, if it wasn't for these browser limitations. People would just make fully new languages, and it is starting to happen with WebAssembly.
And the ecosystem of JVM and BEAM hosted languages does make the concept even murkier.
It's good to be aware of that from an engineering standpoint, because the host language will have significantly different limitations, interoperability and ecosystem, compared to regular binary or some VM byte-code.
Also, I believe that they are meaningfully different in terms of compiler architecture. Outputting an assembly-like is quite different from generating an AST of a high-level programming language. Yes of course it's fuzzy because some compilers use intermediate representations that in some cases are fairly high-level, but still they are not meant for human use and there are many practical differences.
It's a clearly delineated concept, why not have a word for it.