Esta é uma pergunta aberta com muitas respostas possíveis que dependem do que você está tentando fazer. No entanto, adicionarei algumas coisas como resposta, pois um comentário não será grande o suficiente.
O serviço atuaria como um pool de conexão com o banco de dados (acho que mais de 2000 conexões em um banco de dados causariam problemas);
Sim, essa é uma boa ideia. Você mantém um número menor de conexões abertas e as reutiliza à medida que as solicitações chegam ao serviço. Mas você precisa saber com que rapidez as solicitações serão atendidas e quanto cada solicitação utiliza o banco de dados; caso contrário, um pequeno pool pode ser facilmente esgotado e outras solicitações serão bloqueadas enquanto aguarda a liberação de uma conexão com o banco de dados.
O cache pode ajudar lá, para retornar dados já buscados (como eu disse, depende do que você está tentando fazer - se as consultas forem exclusivas, você não poderá armazenar muito em cache).
Observe também que o tamanho do pool será multiplicado pelo número de serviços que você implementa. Alguns serviços e você pode usar tamanhos de pool de banco de dados grandes; mais serviços e você precisa diminuir o tamanho do conjunto, para que você tenha o mesmo número de conexões abertas no banco de dados, em geral.
É possível ter um banco de dados com envio de log para outro banco de dados somente leitura para atender a algumas consultas;
O banco de dados pode facilmente se tornar seu gargalo. Muitas conexões e / ou muitas consultas e você pode quebrá-lo. Nesse ponto, não importa que você possa escalar horizontalmente seus serviços para qualquer número. Todas as solicitações chegarão ao mesmo banco de dados.
Existem várias maneiras de protegê-lo: cache que eu já mencionei (depende do seu caso de uso), duplique algumas informações em outros servidores para atender a algumas consultas, como você menciona, CQRS (depende do seu caso de uso), use um relacional versus não relacional (depende do seu caso de uso novamente) etc.
Observe, porém, que quando você distribui dados assim, o teorema do CAP começa a se aplicar. Esteja ciente disso, pois pode ser necessário comprometer a consistência e a disponibilidade.
Escalaria melhor, pois podemos adicionar mais máquinas para executar os serviços REST;
Sim, o serviço REST será dimensionado, mas, como mencionei acima, se você não proteger o banco de dados, isso poderá se tornar um gargalo facilmente.
É possível usar HTTPS com compactação por motivos de segurança e economia de largura de banda;
Sim, assim como outras coisas ... talvez você queira autenticação / autorização posteriormente, etc.
É possível fazer algumas alterações centralizadas nas entidades comerciais sem reimplementar as mais de 2000 máquinas;
Sim, mas até certo ponto e nem todo tipo de mudança. Se você fizer uma alteração de última hora, também precisará atualizar os clientes. Portanto, pense em uma estratégia para atualizar os clientes para a versão mais recente ou se você permitir que clientes mais antigos ainda funcionem e usem o aplicativo.
Ele se integra melhor a outros sistemas (basta apontar para o serviço REST).
Sim, mas isso significa clientes para o seu serviço que talvez você não possa controlar.
Se você fizer uma alteração de última hora e tiver uma boa estratégia para atualizar seus clientes 2000+ JavaFX, não há problema. Porém, se existirem outros clientes e você não tiver controle sobre eles, poderá ser necessário implementar a versão no serviço REST e oferecer suporte a mais de uma versão até que todos possam atualizar para a versão mais recente.
Como eu disse, depende do que você está tentando fazer. No geral, a sua é uma boa ideia. Mas esteja ciente de que as coisas não serão gratuitas apenas porque você coloca um serviço REST na frente de um banco de dados.
Apenas meus 2 centavos!