From what I've noticed, these "transpilers" output code that is readable (the code itself is written as though a human wrote it) where as "compilers" output code that has been optimized and show effects of name mangling in the code itself, etc. Just an observation.
I think it makes sense to use a different term for this "compiler"-esque behavior. For example, I might edit the output of CoffeeScript generated Javascript whereas I wouldn't know how to modify the output of gcc.
This is even better highlighted by something like the GHC compiler, which compiles Haskell to (ultimately) machine code, because it does this in several steps:
1. As a first step, it "transpiles" Haskell to the very similar high-level intermediate language called Core. I could read and write programs in Core without too much effort because it's still a very high-level language.
2. Then it "transpiles" the Core code to the not significantly lower level STG source code – human readable, but starts dealing in a little lower-level stuff and contains much fewer bells and whistles. I'd prefer not to work in STG, but I totally could if I had to.
3. After this, it again "transpiles" the STG source code to the C-- (C-minus-minus) intermediate language, which is decidedly low-level (slightly lower level than regular C code), but there's still a clear and relatively simple translation between STG and C--.
4. As a final step, it "transpiles" the C-- source code to assembly (a closer match than you may think, coming from C), which can be assembled into machine code.
At no point in this pipeline is there a significant magic translation being made – despite the fact that Haskell is probably one of the most high-level languages we know and machine code is as low-level as you get.
I think it makes sense to use a different term for this "compiler"-esque behavior. For example, I might edit the output of CoffeeScript generated Javascript whereas I wouldn't know how to modify the output of gcc.