Ele é uma limitação de hardware. O shader de fragmento faz parte do pipeline programável, mas a mistura final de cores com o (s) buffer (s) de destino não é programável em hardware de commodity amplamente disponível neste momento (é configurável através dos estados de mistura, mas você não pode escrever arbitrariamente código que substitui as operações de mistura incorporadas das GPUs).
A razão pela qual o hardware não foi construído para isso provavelmente tem a ver com o fato de a GPU ser massivamente paralela; eles processam muitos fragmentos de cada vez. Alguns desses fragmentos podem interagir entre si nos buffers de destino, mas devido à natureza assíncrona do processamento de fragmentos, não é possível saber como até que o fragmento tenha sido processado e a cor final emitida ... sempre acontece deterministicamente.
Só porque o pixel A estará atrás do pixel B no quadro final não significa que o pixel A sempre concluirá o processamento do fragmento e será gravado no destino antes de B, especialmente em vários quadros de renderização. Portanto, o valor lido do buffer de destino durante o processamento do pixel B nem sempre será do pixel A - às vezes serão os valores claros.
Portanto, desconfio que a proibição de leituras diretas do buffer de destino durante o estágio de fragmento tenha muito mais a ver com impedir que o programador de shader se atire no pé, obtendo resultados potencialmente não determinísticos dessa leitura do que com qualquer limitação técnica real para tornar o estágio de mistura totalmente- programável. Ao manter as operações de leitura rigidamente controladas (o teste de profundidade, por exemplo), a GPU garante que as operações realizadas com o valor de leitura façam algum tipo de sentido.
Dito isto, também pode haver uma coisa de custo / benefício acontecendo. Tornar programável esse aspecto do pipeline da GPU complicaria um pouco o design do chip, e a necessidade / demanda de leituras do buffer de destino tem sido relativamente baixa em comparação com outros recursos.