"List Comprehensions" vale a pena?

O uso de List "Comprehensions" em Python eh um bom uso?

Sim, é um bom uso. A ideia principal sempre foi deixar as coisas mais legíveis e concisas - então, a não ser que seja uma expressão complexa, que fique mais legível em múltiplas linhas, seu uso é recomendado - os casos mais simples de list-comprehensions trocam 3 ou 4 linhas de código por uma única linha com menos de 60 colunas. Vale muito a pena.

Afeta a performance do programa (tempo de execução, etc..)?

A diferença é mínima - mas se a ideia é criar uma lista, as list-comprehension são um pouco mais rápidas do que criar uma lista vazia e ir fazendo append - só por que o construtor da lista executa o iterador do "for" direto em código nativo - sem uma chamada ao ".append" pra cada elemento.

Essa diferença é realmente mínima, e não vai ser sentida pra listas de 10, 100 ou 200 elementos, ou trechos de código que sejam executados uma única vez.

Pra listas maiores, em um trecho de programa que rode constantemente (por exemplo, em uma view de uma aplicação web com vários acessos concorrentes), pode começar a fazer diferença real.

Já o uso que você faz, para fazer o "print", realmente não é o mais usual - normalmente se usa list-comprehension quando você quer os valores mesmo. Mas quando estamos no modo interativo (seja no ipython, em um notebook, ou no pdb), essa sintaxe pod ser um bom atalho pra ver o conteúdo de várias coisas - e aí não há contra-indicações.

Mesmo que fosse uma lista com algumas dezenas de milhares de elementos "None", a diferença de performance/consumo de memória para uma única execução sequencial é negligível, quando comparamos o tamanho dessa estrutura com todo o processo da app Python, que inclui o runtime do cpython: não vai fazer nem cócegas

Apesar disso, é importante ter em mente que uma construção muito parecida com as list-comprehensions, as "generator expressions", funcionam de forma muito mais racional nesse sentido - é a mesma coisa, mas sem ser delimitada por [ e ], e sim, só por parênteses (e as vezes até sem nada, se o contexto permitir).

As generator expressions só avançam um passo no seu "for" quando um elemento vai ser "consumido" por uma estrutura de fora delas- e não guardam o elemento - então não há esse "gasto" de memória.

Só que uma generator expression sozinha também não é executada - alguém tem que "consumir" seu conteúdo.

Ou seja:

(print(x) for x in range(11) if x % 2 == 0)

não faz nada: o Python prepara o objeto, pronto para criar os valores de x e chamar o "print", mas enquanto um for ou uma outra função para onde você passar essa generator expression como parâmetro não consumir os valores, o for nunca avança e o print não é executado. (A função "next" avança um generator de 1 em 1 se alguém optar por fazer o que o for faz manualmente)

Por exemplo, a função any espera um iterável, e ela consome todos os valores até chegar no primeiro que não seja equivalente a um "False" booleano. Como o "print" retorna "None", ela consumiria isso até o final:

any(print(x) for x in range(11) if x % 2 == 0)

(perceba também que se não houver ambiguidade, não é preciso por um par de parenteses exclusivo para a generator expression, como mencionado acima).

Um padrão de uso mais comum é, em vez de colocar o print dentro da estrutura de repetição, manter a estrutura de repetição só gerando os valores desejados, e passa-la como parâmetro para o método join de uma string, que já cuida da formatação.

O único detalhe é que cada elemento de um iterador que o "join" consome tem que ser uma string.

Mas, resumindo, isso aqui é considerado de "boa qualidade" para estar em código de produção (embora isso seja um pouco subjetivo):

print(", ".join(str(x) for x in range(11) if not x % 2))

E só pra manter a resposta completa, é importante lembrar que também existem os "dict comprehension": {chave: valor for chave, valor in iteravel} e os "set comprehensions": {elemento for elemento in iteravel} - as mesmas ideias se aplicam para ambos.