Q:

Quais os motivos para escolher entre camelCase e PascalCase em nomes de métodos?

Primeiro, não estou querendo saber o que você gosta mais ou o que usa na sua linguagem, quero saber a motivação para escolher um ou outro padrão em uma linguagem hipotética.
Segundo, isto é um pouco estilo de codificação, que na verdade você deve seguir o padrão que a linguagem adotou, mas principalmente sobre porque uma linguagem adotaria assim. Não é sobre uma linguagem existente, vou as citar para exemplificar o que quero.
Um exemplo bem típico é o Java ter adotado camelCase e o C# adotou o PascalCase. Eu tenho um bias hoje para o PascalCase, não sei bem porque mas assim que vi o PascalCase fez muito sentido pra mim, mesmo tendo adotado camelCase antes em outras linguagens. Mas meio que só C# o adotou. Eu olho aquilo e sinto que está melhor padronizado, parece algo da estrutura do código e diferencia da variável que faz parte do algoritmo.
Meio que todo mundo adotou o PascalCase para nomes de tipos e até de namespaces. Em C# não diferencia nada para o método, mas são contextos diferentes, o IDE coloca cor adequada. Java, JS, e outras preferiram deixar claro que é um método de uma forma diferente, ao mesmo tempo que confunde com nomes de variáveis, exceto pelos parenteses que quase sempre é usado, mas não em todos casos. No começo Java nunca tinha essa confusão, hoje tem, JS tinha como confundir, mas não foi uma linguagem bem pensada (PHP tem um pouco das duas coisas, não confundia no começo e não foi bem pensada, ela nem respeita sempre isso). C# nasceu sabendo que isto poderia ser confuso.
Eu gosto da ideia do camelCase, mas parece feio (é bem subjetivo mesmo). Considero isto um aspecto da UX do programador e por isso considerando o design de linguagem, porque escolher o estilo padrão não deixa de fazer parte desta disciplina, então queria entender a motivação de uso de cada um.

A:

Primeiro um pouco de história
Essa resposta é baseada nesse excelente artigo do Celso Kitamura https://celsokitamura.com.br/pascal-case-e-camel-case/
Em 1813 Jacob Berzelius, químico, sugeriu uma convenção para formaliza a forma de escrever as fórmulas químicas. Ele propôs indicar cada elemento químico por um símbolo de uma ou duas letras, sendo a primeira em maiúscula. Veja o Exemplo abaixo:

No exemplo da fórmula NaCl teríamos SódioCloro = Cloreto de sódio, mesmo naquela época não havia um conceito único para escrever fórmulas químicas, e essa proposta foi adotada para normalizar a escrita, e posteriormente acabou virou regra. Foi algo que facilitou a vida do usuário, pois gera menos erros e é de fácil compreensão e utilização na hora de escrever fórmulas e elementos.
Essa é a convenção adotada na tabela periódica, e que posteriormente foi aplicada em outros meios como na programação.

Os pontos cardeais por sua vez utilizam de outra convenção por exemplo.

Ainda entre as décadas de 70 e 80 não existia bem um padrão, por N motivos, vou tentar aborda-los em outro momento. Mas o que se viu foi o Camel Case ou Pascal Case serem adotados culturalmente, e apesar de não ser regra são incentivados.

No caso do .NET, a Microsoft recomenda:

Usar Pascal Case para todos os nomes de membros, tipos e namespace públicos que consistem em várias palavras.
PropertyDescriptor
HtmlTag
Usar Camel Case para nomes de parâmetros.
propertyDescriptor
htmlTag

Aqui tem uma lista com o Naming_Convention de vária linguagens, para refletir no que elas têm em comum, prós e contras, etc. (C e C++, Java, JavaScript, .NET, PHP, Python, Ruby, etc.): https://en.wikipedia.org/wiki/Naming_convention_(programming)

Fornecer informações adicionais (ou seja, metadados) sobre o uso para o qual um identificador é colocado;
Ajudar a formalizar expectativas e promover consistência dentro de uma equipe de desenvolvimento;
Permitir o uso de ferramentas automatizadas de refatoração ou pesquisa e substituição com potencial mínimo de erro;
Aumentar a clareza em casos de potencial ambiguidade;
Para melhorar a aparência estética e profissional do produto de trabalho (por exemplo, desaprovando nomes excessivamente longos, nomes - Cômicos ou "fofinhos" ou abreviações);
Para ajudar a evitar "colisões de nomenclatura" que podem ocorrer quando o produto de trabalho de diferentes organizações é combinado (consulte também: namespaces);
Fornecer dados significativos para serem usados ​​em transferências de projetos que requeiram o envio do código-fonte do programa e toda a documentação relevante;
Para fornecer melhor entendimento em caso de reutilização de código após um longo intervalo de tempo.

Uma palavra é uma chave

Repare como a variação de altura da linha ascendente entre maiúscula é minúscula cria um pattern visual, que pode ser usado para reconhecer facilmente as palavras. Esse variação na frequência das letras ajuda o olho a reconhecer padrões e palavras de forma mais rápida. Já quando esta tudo em CAIXA ALTA, a linha não varia, fica reta, e para reconhecermos a palavra precisamos realmente ler com mais atenção.
var UmaChaveUtil //(3 variações de Case)
var umaChaveUtil //(2 variações de Case)

Uma "chave" com mais variações de "segredo" pode ser mais útil e melhor para o reconhecimento de maneira geral... (falarei mais disso abaixo)

Além das convenções - Aspectos tipográficos e de UX
Independente da linguagem outros pontos devem ser levados em consideração. Por exemplo, qual a dificuldade de se escrever PalavrasLongasEmCamelCase? Qual a leiturabilidade disso? Em um mundo de palavras é mais fácil reconhecer UmaPalavra ou umaPalavra. A escaneabilidade é muito importante na hora de identificar palavras específicas no meio de outras. E nesse artigo do NNGroup existem boas pistas das práticas que você pode adotar e que vão apresentar uma melhor UX https://www.nngroup.com/articles/glanceable-fonts/.
Independente de ser adotado Camel ou Pascal o sistema é case sensitive? Usar essas regras vão resultar em mais erros ou menos erros, é mais fácil de escrever ou de ler? Para um sistema que ainda não existe, considere fazer um Teste A/B. As palavras reservadas pode seguir uma convenção, já as classes que são nome próprio podem ter outra... Então até mesmo uma Pesquisa Qualitativa pode ser interessante nessa faze, algo que é muito comum de se fazer em UX e Design Thinking.

4° Lei da heurística: Os usuários não devem se perguntar se palavras, situações ou ações diferentes significam a mesma coisa.

Quando se fala em heurística o principal fator talvez seja a consistência, então ter regras claras evita erros e deixa o usuário mais confortável. Então ao definir uma regra, evite deixar que coisas como essa sejam válidas, pois além de não ter coerência, pode ser ambíguo e confundir o usuário.
Fonte: https://www.nngroup.com/articles/ten-usability-heuristics/

Repare novamente na imagem acima. Será que o usuário poderia entende "Calendário" de forma diferente que "calendário"? Não posso afirmar, mas pode ser que as pessoas entendam isso de forma diferente, um calendário pode ser um calendário qualquer, já o Calendário, pode ser o App de Calendário.
Proeminência Visual

Repare na imagem acima, veja como um título com Cases variados parece se destacar mais do que o outro só com a letra inicial maiúscula.
Fonte: https://medium.com/@jsaito/making-a-case-for-letter-case-19d09f653c98
Um pouco de opinião

Quando você pensa em sistemas, as palavras reservadas ou palavras padrão da linguagem, ou que se repetem a todo o momento e são iguais para todos, poderiam ser "mais discretas", já as variáveis ou classes (como no CSS), que são palavras que o usuário "inventa" (e que cada um pode escrever de um jeito), você poderia definir regras claras. Pois como são palavras concebidas  pelo próprio usuário regras poderiam ser melhor que boas práticas. Essa seria uma maneira de normalizar a escrita independente de quem escreve. No CSS .classe é diferente de .Classe, mas os dois funcionam... Isso é bom ou ruim? Logicamente depende, mas se só fosse permitido uma das formas poderia ser melhor para o usuário. O usuário gosta de seguir padrões, e o olho aprende a achar padrões... E o Pascal Case pode ser um padrão mais fácil para o usuário identificar palavras não originais da linguagem (palavras que são definidas por outros usuários). Mas como falei, mais pesquisas e testes devem ser feitos.
Exemplo de tabela com regras claras:

Gestalt
Quando se fala em "reconhecimento de padrão" lembre-se que nem tudo que vemos estamos na verdade lendo. Um dos princípios da Gestalt é o reconhecimento de formas. O olho humano e o cérebro sempre tendem e reconhecer formas e padrões. E isso pode ser fundamental para a escaneabilidade do código. É como um artifício que pode auxiliar a reconhecer rapidamente palavras no meio do texto.

Como nosso cérebro utiliza parâmetros de leitura visual, ao enxergarmos um composto de elementos (sejam eles objetos, pessoas, paisagens, animais ou textos), a tendência é agrupar características que sejam semelhantes, de forma que sua interpretação seja a mais rápida possível.

Fonte: https://whitecom.com.br/8-principios-da-gestalt/
Wiki da Gestalt: https://pt.wikipedia.org/wiki/Gestalt

Embora seja sabido há algum tempo que o texto de tamanho maior é mais legível, este estudo mostrou que o peso e o processo também são importantes. As letras minúsculas exigiam 26% mais tempo para leitura precisa do que letras maiúsculas, e o texto condensado exigia 11,2% mais tempo do que o normal. Também houve efeitos significativos de interação entre o caso e o tamanho, sugerindo que os efeitos negativos das letras minúsculas são exacerbados com pequenos tamanhos de fonte.

Antigamente as IDEs, Terminais e Prompts não eram tão customizáveis, eles tinham um font-size padrão assim como um font-family padrão, e cor. Tudo foi pensado para o usuário ter uma melhor experiencia. Então as escolhes tipográfica também estão ligadas a forma como você vai escrever. Já é comprovado que textos longos não devem ser escritos todo em maiúsculo, assim como fontes mais "condensadas" são mais difíceis de serem lidas.

Repare no formato dos "shapes" veja como o UpperCase é mais difícil de identificar o caractere, principalmente pela "falta" de contraste por não ter descendentes (p) e ascendentes (d) na base-line e caps-line.

Veja como uma fonte com a "Altura de X" pequena é mais difícil de perceber a diferença entre Upper e Lower case (a primeira fonte tem o X Height menor).

Auto regulamentação
Mas quando a linguagem é livre o que se vê é o surgimento de convenções, seja de escrita ou de organização, como é o caso do CSS e suas metodologias de nomenclatura como OOCSS, SMACSS, BEM, DRY. Site com alguns exemplos e definições https://tableless.com.br/oocss-smacss-bem-dry-css-afinal-como-escrever-css/ vale dizer que para cada uma delas existem prós e contras, mas escolhendo um padrão regras devem ser seguidas, mesmo em uma "linguagem" que não tem regras :)

E no Mobile?
Já pensou como pode ser cansativo escrever variando entre maiúsculas em minúsculas em um dispositivo Mobile? Ainda mais com o corretor ortográfico tentando transforma o camelCase toda hora? Esse é um ambiente que certamente teria que ser estudado para avaliar o que seria mais fácil e produtivo para o usuário trabalhar. Não achei dada que se refira ao assunto, mas talvez o kebab-case (palavras com hifenização) sejam mais fácil de digitar no celular.

Então todas essas escolhas podem influenciar na UX e na escolha do que adotar...
Livro recomendado Design-Time Web Usability Evaluation with Guideliner: https://site-109191.mozfiles.com/files/109191/2228-7961-1-SM.pdf
OBS 1: O artigo do NNGroup citado acima feito com palavras "avulsas" e não em textos corridos. Ele não aborda especificadamente Camel Case ou Pascal Case, e inclusive sugere que se façam mais estudos.
OBS 2: Não abordei no assunto, mas pense também qual dos dois estilos seria mais interessantes para os Dislexos. Pensando em acessibilidade e inclusão seria legal ter mais informações e levar em conta como uma pessoa com dislexia ou TDAH interagem com esses tipos.

