A resposta que sim, as funções theme_mod serão mais lentas, mas não significativamente, e os benefícios superam as diferenças.

Mods de tema são armazenados como opções. Então, em essência, as funções theme_mod são wrappers em torno das funções de opções.

Primeiro, entenda que as configurações de theme_mod são armazenadas como uma matriz em uma única opção, codificadas para o nome do tema específico. Então, se eu fizer isso:

set_theme_mod('aaa',123);
set_theme_mod('bbb',456);

Então, o que eu realmente obtenho no banco de dados é uma única linha de opções com o nome theme_mods_themename que contém um array serializado com ('aaa' = > 123, 'bbb' = > 456) nele.

Agora, get_theme_mod será mais lento porque, na verdade, está realizando duas chamadas get_option . Primeiro, obtém o nome do tema. Então, ele obtém a opção theme_mods_themename . Então aí está uma perda de velocidade de 50%. O resto do trabalho é feito principalmente em filtros, em que há uma chamada de filtro extra, mas a menos que você tenha algo nesse filtro, isso é meio insignificante.

Observe que o sistema de opções armazena os dados recuperados no cache de objetos, portanto, não está fazendo várias chamadas de banco de dados aqui. Somente o primeiro uso resulta em um acerto de banco de dados.

O set_theme_mod será um pouco mais lento porque faz com que as mesmas duas opções recebam chamadas, em seguida, faz outra chamada get_option para obter o nome do tema novamente e, em seguida, update_option com o conjunto completo alterado opções. Isso causa uma atualização do banco de dados, e o fato de estar enviando muito mais dados pode, de fato, ser a causa de uma desaceleração perceptível. Atualizar alguns bytes é mais rápido do que atualizar uma linha maior. Mas não tanto quanto você notaria, normalmente. A menos que você tenha um monte de configurações ...

As funções de modificação de tema provavelmente são devidas para otimização geral, certamente, mas mesmo assim você ainda deve usá-las em vez de get_option e por causa de temas infantis.

O problema de usar linhas de opções diretamente é que você as está usando diretamente e usando nomes de chaves específicos para suas configurações.

Se eu tiver um tema chamado "AAA" e criar um tema filho chamado "BBB" para uso em outro site, meu tema "AAA" poderá usar uma opção chamada "example". Quando eu atualizo um site e ele atualiza minha opção, a mesma opção será aplicada ao meu tema filho. E se eu não quisesse isso? E se eu quisesse que o tema filho usasse um conjunto diferente de configurações de opção?

Os modificadores de tema, incluindo o nome real do tema (e não um valor codificado) como parte da chave, garantem que cada "tema" no site use seu próprio conjunto de configurações. Eu posso alternar e as configurações não são transferidas entre elas, elas ficam como eu as defini. Mais simples, mais óbvio, mais intuitivo.

E se alguma mudança no núcleo ou plugin futuro modificar a forma como o theme_mods funciona, você obterá automaticamente os benefícios sem alterações. Os invólucros sempre serão mais lentos, isso é inevitável, é a natureza dos invólucros. No entanto, você ainda está escrevendo código PHP, não linguagem de máquina. Usamos wrappers como este para simplificar as coisas e separar a funcionalidade. Os temas não precisam saber, ou se importar, como suas opções são armazenadas no banco de dados ou como a nomeação funciona. As funções theme_mod fornecem uma solução mais simples e mais limpa.

get_theme_mod é apenas um wrapper em torno de get_option . Em teoria, porque é outra camada de abstração, ela funcionará mais devagar, mas, na prática, a diferença não deve ser grande o suficiente para ser percebida por um ser humano.

Diferenças de velocidade reais podem ser causadas se você tiver algum código lento conectado aos ganchos theme_mod.

Poderia haver algo acontecendo no Customizador? Eu estou vendo a mesma coisa que o OP aqui.

Posso confirmar que, com cerca de 30 opções, o tempo de carregamento do meu Personalizador caiu de cerca de 3 s para cerca de 0,5 s ao alternar para get_option over get_theme_mod

Chamando os métodos diretamente, vejo uma diferença de 2 ms.

( enlace )

Pode não ser perceptível quando você compara as APIs diretamente, mas deve haver algo com o modo como elas são utilizadas no Customizador.

Você pode TESTE O TEMPO de get_option (100 iterações) usando este código (coloque em functions.php ou em algum lugar):

add_action('wp','My_Test');
function My_Test(){
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_option('blogdescription'); }
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_theme_mod('blogdescription'); }
    var_dump(microtime(true));
    exit;
}   

Outros pensamentos

Eu não sei, se isso faz diferença (talvez os desenvolvedores do Wordpress saibam melhor), mas eu pensei, que se um site tem tráfego ALTO, e em cada carregamento de página, ele precisa ter centenas de opções, e se Eu unirei muitas opções em um get_option ? assim:

update_option('my_extra_optss',  array(
      'myNAME' => 'George',
      'myAGE'  => 43 ));

então:

$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................

isso tornará o site um pouco mais rápido?