Beh, quel valore teoricamente (e stando anche alle vecchie versioni del "rinnovato" motore grafico) carica solamente più zone esterne in RAM. Sostanzialmente non vedi differenze, se non dopo parecchio tempo passato a correre in una direzione, cioè fino al punto in cui ti manca quel pezzo di mappa caricato in memoria.
Incrementare le celle non ha effetto sulla fluidità, bensì sul numero di caricamenti:
se con 36 carichi una zona grande come Milano (esempio), con 108 carichi Milano, Torino e Genova, con il gioco che ti gira alla stessa velocità della Milano con buffer celle 36, ma per tutte e 3 le città.
Se con 36, nel passaggio tra Milano a Genova doveva caricare, con 108 è stato precaricato, quindi non deve perdere tempo ad aggiungere il pezzo mancante.
Il vantaggio è relativo, purtroppo è stato mal gestito a livello di programmazione, era un parametro implementato molto meglio (anche se in maniera molto "instabile") su Oblivion o Fallout 3.
Per quanto riguarda invece la riga mancante, credo sia dovuta al fatto che è stata eliminata la voce uInterior Cell Buffer, presente invece nei giochi sopracitati.
Ad ogni modo, in un file ini la riga mancante non dà problemi, perchè il programma, ad ogni passaggio per il controllo dei parametri, effettua dei cicli di controllo delle voci fino a EOF (end of file), quindi pure con 5000 spazi tra le varie linee l'ini funziona ugualmente.
Non c'è quindi alcun bisogno di essere paranoici, di certo non con questo tipo di file
