No mercado como um todo, quando a solução não tem que ser multiplataforma, geralmente cai para a solução microsoft ou borland, que são mais produtivas.
Quando é necessário ter uma solução multiplataforma e desktop (um nicho mais específico), caso escolha Java (mais específico ainda), a tendência é escolher Swing pois há mais informação para pesquisar devido ao tempo de vida e componentes.
Agora valer mais o Swing do que o JavaFx acho que depende, acredito que pra fazer o básico CRUD ou fluxos simples o Swing atende (90% casos acredito), mas quando é necessário algo mais específico, as coisas tendem a dificultar.
Um vez precisei salvar coordenadas geográficas baseados no clique do usuário em um mapa fornecido pelo google maps, fazer isso no web é relativamente simples atualmente, mas exige bem mais trabalho em Swing. Outro exemplo foi quando precisei colocar um navegador web em uma aba numa aplicação Swing, só foi possível resolver apelando para JNI e JNA e obter os componentes diretamente da biblioteca do SO, e te digo que essa biblioteca não retorna muita informação quanto a erros de Javascript.
Isso porque nem entrei em componentes que usam o sistema multimídia do SO como som, vídeo e renderização, que no caso do Swing é necessário usar o antigo JMF ou framework de terceiros. Tive uma dor de cabeça para atender um cliente que queria gerar um gráfico em tempo real pela voz, a aplicação tinha que ser para desktop, android e ios. Como não tinha tempo de aprender Cordova (o que tinha na época) JavaFx com o Gluon salvou o dia, em 1 mês o protótipo tava pronto rodando nas 3 plataformas.
Acho que infelizmente o JavaFx foi mal apresentado, quando apareceu tentou pegar o mercado do famigerado Flash, depois tentou ir na onda das interfaces ricas. Se simplesmente tivessem apostado desde o início em uma extensão do Swing (como o mesmo foi para o AWT) a adesão seria mais simples e favorável.
Hoje acredito que para desktop multiplataforma Java se torna a última opção devido as alternativas.
