Q:

O que é mais rápido para ser lido e editado, um banco de dados ou um .txt?

Seria para armazenar e reescrever apenas 1 dígito INT, apagando um e escrevendo outro, na condição de que quando chegar a 5, voltar pro 1, e ir fazendo esse loop toda vez que alguém acessar.
Sempre que alguém acessar a página, o valor seria acrescido de +1 e gravado, exceto que já tivesse em 5, aí voltaria pro 1.
Enfim. PHP + MySQL, ou PHP + .txt, qual é mais rápido para essa finalidade?
Considerando que se fazendo centenas de requests simultâneos não bugue o sistema, qual é melhor? 

A:

Um arquivo texto flat será sempre mais rápido, ele não tem que fazer quase nada. Um banco de dados executa um conjunto monumental de coisas para garantir a integridade dos dados e fazer isso de uma forma fácil e padronizada.
Isso não quer dizer que seja a melhor opção. Se for acessar o arquivo concorrentemente tem que saber o que está fazendo, caso contrário terá problemas, mesmo em um padrão simples como o relatado.
O que não cria bugs no sistema é dominar todo o processo de desenvolvimento de software, implantação e manutenção da infraestrutura. Isso não é só saber se é melhor usar MySQL ou .txt. Mas se não sabe o que é melhor, vá no mais seguro que é o banco de dados. Pelo menos ele exige menos cuidado.
Uma alternativa intermediária seria o uso do SQLite que possui as características do banco de dados com algumas facilidades do acesso ao arquivo, incluindo melhor performance.
Em alguns casos outro banco de dados pode ser mais útil, quem sabe um NoSQL.

A:

Segundo o que descreveu, haverá centenas de conexões simultâneas. Cada conexão incrementa um valor e quando chegar a 5, volta ao valor 1.
Com arquivo txt isso pode ser um problema pois terá que criar condições para impedir inconsistências.
Uma lógica é travar a edição ou acesso ao arquivo caso já esteja aberto por algum usuário:
$f = fopen('fit.txt', 'a');
if(flock($f, LOCK_EX | LOCK_NB)) {
    $n = fread($fp, 4);
    ($n == 5)? $n = 1: $n++;
    fwrite($f, $n);
    flock($f, LOCK_UN);
}
fclose($f);

Usando um banco de dados essa operação é mais segura, no entanto, é óbvio que terá um custo muito maior de processos.
Antes de pensar em performance, pense em consistência. Se a rotina é segura e tem certeza de que não haverá falha, você vai para o "próximo estágio" que é a otimização.
Nesse exemplo acima com flock(), o processo é "super rápido" mas ainda assim pode acontecer alguma falha. Algo inexperado onde demore muito para liberar para o próximo usuário.
Imagine então um cenário onde 200 usuários acessaram no mesmo exato tempo.
O primeiro será o "sortudo". Vai ler e escrever o número e liberar para o segundo, terceiro, quarto. Mas o que estiver por último na fila conseguirá ler e escrever o valor corretamente ou retornará algum erro por longo tempo de espera?
Considere que se o sistema tem centenas de acessos simultâneos, digamos que num único segundo receba 150 conexões e depois de 2 segundos mais 200 e depois de 2 segundos mais 100. Só aí você já tem, num espaço de 5 segundos, 350 neguinho na fila de espera para ler e escrever nesse txt. O sistema pode interromper a execução por volta do número 200 devido a longa espera. 
Pode ser o caso de repensar a lógica do negócio.
Caso não tenha essa grande quantidade de conexões simultâneas, aí sim, o simples flock(), como no exemplo, pode resolver e ser ainda uma opção mais viável que um banco de dados, em termos de performance.

