Q:

Qual é a vantagem de usar linguagens que compila pra outras linguagens?

Estávamos discutindo no chat do Stackoverflow sobre linguagens como Moonscript e CoffeeScript.
São duas linguagens que compilam para outra linguagens. Moonscript para Lua e CoffeScript para Javascript.
Eu percebi em relação às duas que a sintaxe das duas muda muito em relação à linguagem que se intenta compilar.
Exemplo de Moonscript:
class Thing
  name: "unknown"

class Person extends Thing
  say_name: => print "Hello, I am #{@name}!"

with Person!
  .name = "MoonScript"
  \say_name!

Que é compilado para Lua da seguinte forma:
local Thing
do
  local _base_0 = {
    name = "unknown"
  }
  _base_0.__index = _base_0
  local _class_0 = setmetatable({
    __init = function() end,
    __base = _base_0,
    __name = "Thing"
  }, {
    __index = _base_0,
    __call = function(cls, ...)
      local _self_0 = setmetatable({}, _base_0)
      cls.__init(_self_0, ...)
      return _self_0
    end
  })
  _base_0.__class = _class_0
  Thing = _class_0
end
local Person
do
  local _parent_0 = Thing
  local _base_0 = {
    say_name = function(self)
      return print("Hello, I am " .. tostring(self.name) .. "!")
    end
  }
  _base_0.__index = _base_0
  setmetatable(_base_0, _parent_0.__base)
  local _class_0 = setmetatable({
    __init = function(self, ...)
      return _parent_0.__init(self, ...)
    end,
    __base = _base_0,
    __name = "Person",
    __parent = _parent_0
  }, {
    __index = function(cls, name)
      local val = rawget(_base_0, name)
      if val == nil then
        return _parent_0[name]
      else
        return val
      end
    end,
    __call = function(cls, ...)
      local _self_0 = setmetatable({}, _base_0)
      cls.__init(_self_0, ...)
      return _self_0
    end
  })
  _base_0.__class = _class_0
  if _parent_0.__inherited then
    _parent_0.__inherited(_parent_0, _class_0)
  end
  Person = _class_0
end
do
  local _with_0 = Person()
  _with_0.name = "MoonScript"
  _with_0:say_name()
end

Quais são as vantagens e desvantagens de se utilizar uma linguagem que compila para outra linguagem?

A:

Desvantagens
Generalizando assim, nenhuma :P Só tem desvantagens.
Claro que se olhar especificamente pode existir vantagens.
A compilação para outra linguagem em si não é um problema tão grande, ou sequer é um problema, afinal boa parte da linguagens são compiladas para linguagem de máquina.
O problema aparece quando esta linguagem alvo (este é o nome que se dá para a linguagem que terá o código gerado depois da compilação inicial) precisa de uma compilação e principalmente de interpretação.
O problema é que cria-se um passo a mais, exige um software extra. E o resultado é o código de outra linguagem que tem uma estrutura próprio. É bem complicado criar ferramentas para depurar o código na linguagem fonte (a que foi escrita o código originalmente). Tem que fazer um mapeamento e interceptar a execução para acompanhar a execução do código final como se fosse o código original.
Além disto, normalmente a interoperabilidade pode ficar limitada.
A implementação do compilador da linguagem fonte é boa? Se não for você pode ter problemas. Terão ferramentas auxiliares adequadas e suficientes?
Se a linguagem alvo mudar de forma incompatível a linguagem fonte pode ficar em situação complicada.
Obviamente que a linguagem fonte pode ficar um pouco limitada à capacidade e modelo que a linguagem alvo trabalha.
Linguagens alvo
Tirando a linguagem de máquina as linguagens alvo mais usadas para isto são C/C++ que são universais nos computadores (plataformas), possuem um modelo de eficiência, possuem compiladores muito bons, e são muito poderosas e flexíveis. Elas são usadas para evitar criar um compilador que gera um código mais baixo nível com otimizações agressivas.
Linguagens Assembly (não confundir com código de máquina) de um processador ou uma máquina virtual ou ainda código intermediário de compiladores também são usadas, mas é por um motivo um pouco diferente do foco da pergunta.
Outra linguagem bastante usada como alvo é o JavaScript justamente por ser não só universal no navegadores, mas também porque era (não é mais) a única opção nesta plataforma. Qualquer linguagem que pretenda rodar em um navegador terá que usá-la como alvo. Agora tem a WebAssembly.
É possível que o compilador de uma linguagem compile ela para ela mesma. Isto ocorre quando a linguagem usa açúcar sintático. Claro que isto ocorre internamente no compilador, nem se percebe. E a linguagem sabe como lidar com isto.
Existem linguagens que compilam para várias outras para aproveitar múltiplas plataformas. Claro que há um mínimo denominador comum aí e isto costuma ser ruim. Haxe é um exemplo.
Vantagens
JS é conhecia por ser uma linguagem limitada para criar grandes bases de código e com uma sintaxe que poderia ser um pouco mais simples. Então várias linguagens foram criadas para dar uma experiência melhor para os programadores.
Em geral estas linguagens em cima de outras são criadas porque a linguagem alvo não facilita algum estilo ou paradigma de codificação. Como as linguagens alvo são turing complete elas podem simular qualquer paradigma.
Há casos de exagero em usar este tipo de solução. Pense no caso do MoonScript que provavelmente facilita criar um código Lua que funciona em um jogo. Imagine a dificuldade de depurar este código em um jogo.
A vantagem precisa ser muito grande para compensar. Eu evitaria usar isto em linguagens de script, mas as pessoas usam as linguagens de script pelos motivos errados, então sei lá...
Tem informações sobre trans-compilação na Wikipedia

A:

As maiores vantagens são o reaproveitamento de código, interoperabilidade e a possibilidade de utilizar uma linguagem num ambiente que normalmente não lhe daria suporte.
O projeto de uma linguagem de programação, desde sua sintaxe e semântica até a forma final como ela será implementada (seja compilada, interpretada ou algo no meio do caminho) é bastante complexo, mas há desejo por parte de muitas pessoas de projetar novas linguagens, por razões diversas. Só nessa década foram lançadas 16 novas linguagens (inclui versões maiores de algumas já existentes, tipo C++11 e C++14, mas mais da metade são novas), e há ao menos 25 famílias de linguagens.
Esse projeto tem um custo elevado (nem que seja de tempo), e este seria ainda mais elevado se cada linguagem implementasse todo o software stack desde o parsing até a geração de código de máquina, otimizações, profiling, etc. Reaproveitando os recursos de uma segunda linguagem se reduz significativamente a barreira de entrada e o "time to market", de modo que as linguagens podem ser implementadas, testadas, aprimoradas, ou mesmo descartadas (se os benefícios pretendidos com a linguagem não se concretizarem), de forma muito mais ágil. Ou seja, ideias podem ser testadas, e se ganharem tração, o esforço extra de dar uma implementação adequada fica mais justificado.
Quanto à interoperabilidade, temos os [muitos] casos em que há um sistema legado que não pode ser substituído sem um custo adicional expressivo, mas é desejável que novos módulos sejam desenvolvidos usando recursos modernos de programação. Implementar uma linguagem em cima de uma plataforma já existente (ex.: Jython na JVM ou IronPython no .NET) costuma resolver esse problema de forma mais satisfatória que estabelecer "pontes" entre as diferentes linguagens (em especial pelo fato de muitas terem modelos de processamento/memória diferentes, o que dificulta a interoperabilidade).
Quando a plataforma por baixo não é tão "abstrata" (ex.: JavaScript nos browsers), gerar código na linguagem alvo e deixar que esse código seja compilado pode oferecer uma performance bastante superior do que simplesmente escrever um interpretador nessa linguagem, por exemplo.
Por fim, há a questão de utilizar a linguagem num ambiente não projetado para receber novas linguagens. O caso do browser é o mais óbvio (e vale tanto pra JS quanto pra HTML e CSS), mas há outros. Um particularmente interessante é o caso do GLSL, que é compilado para a GPU - escrever um compilador para uma linguagem diferente, que gere código compatível com a diversidade de GPUs existentes no mercado, seria uma tarefa insana... E se um sistema (inclusive jogos) possui uma "linguagem de script" própria, e a mesma é vista como insatisfatória, gerar código para a mesma pode ser o único meio de se usar uma linguagem distinta nesse ambiente.
Quantos as desvantagens, o Maniero já explicou muito bem (tanto na resposta a essa pergunta quanto à uma pergunta relacionada), não tenho nada de significativo a acrescentar.

