No TCP, o tamanho da janela é um campo não assinado de 16 bits, indicando quantos bytes de dados o receptor tem atualmente para receber.
Acontece que 16 bits não eram suficientes, já que isso só permitiria que 64KB de dados estivessem em vôo a qualquer momento. É por isso que a opção de dimensionamento de janelas foi introduzida. Com o escalonamento de janela, o campo ainda tem apenas 16 bits, mas não precisa contar bytes individuais, em vez disso, ele pode contar com 2, 4, 8, ... ou 16384 bytes de uma só vez.
Os detalhes exatos de como o dimensionamento de janelas funciona não são relevantes para sua pergunta. Porque a explicação que você cita indica que a opção tcp_workaround_signed_windows só se aplica quando a escala da janela não é usada.
O motivo pelo qual a opção só se aplica quando o dimensionamento de janelas está desabilitado provavelmente é que é uma solução para um bug visto apenas em sistemas tão antigos que eles não suportam o dimensionamento de janelas.
O bug
A cite menciona um receptor de bugs que trata o campo de tamanho da janela como um valor assinado. Isso significa que, para todos os valores de até 32 KB, ele funciona corretamente, mas qualquer valor de 32 KB ou mais será interpretado incorretamente como um número negativo.
O efeito disto é que se você disser a um par com este bug que você atualmente tem memória para receber mais 48KB de dados, o par interpretará incorretamente isto como -16KB e parará de enviar mais dados, já que os próximos 1.4KB querem enviar claramente não vai caber. (Ou pode fazer algo ainda mais bobo do que quando vê um valor negativo em um campo que sempre deveria ser positivo.)
Se você se deparar com esse bug, verá que, ao se comunicar com computadores específicos que executam algum software muito antigo, a transferência de dados será interrompida sem nenhum motivo.
Isso pode ser contornado por nunca enviar um tamanho de janela maior que 32KB, o que eu esperaria que a configuração fizesse com essa descrição.
O que a configuração faz?
A redução do tamanho da janela utilizável de 64 KB para 32 KB evitará quedas de conexão durante a comunicação com uma implementação TCP que sofra desse bug.
Isso tem um custo. Se a velocidade de transmissão for limitada pelo tamanho da janela, reduzir a janela para metade do tamanho também reduzirá a velocidade de transmissão pela metade. Então, as transmissões que já estavam funcionando mais devagar do que deveriam poderiam chegar a apenas metade da velocidade.
E é por isso que tal solução alternativa não está permanentemente ativada.
Por que trabalhar apenas com o problema quando o dimensionamento de janelas não é usado?
Não há conexão direta entre o erro e o dimensionamento da janela. Então, eu estou supondo que a única razão pela qual o escalonamento de janelas é considerado é porque é a heurística mais conhecida para detectar uma implementação específica de bugs.
E, de fato, parece provável que tal bug seja corrigido antes que alguém comece a implementar o dimensionamento de janelas. Afinal, se você precisa de janelas maiores, seria tolo não consertar um bug limitando o tamanho da janela à metade do que seria.