Purga stringhe PHP

[.Kurt]

A dir la verità non lo fa minimamente, perchè non tiene conto di XSS e quindi di pezzi html, css o javascript

Usi prepared statement per inserire in sicurezza i tuoi dati nel database, questo è tutto. Cosa fare con quei dati è un problema tuo: quando li salvi il database non è onnisciente al punto tale da sapere dove vorrai usarli ed in quale contesto.
La tua intenzione è di rimediare tu stesso "purgando" i dati prima di salvarli, ed utilizzandoli così come sono quando li vai a recuperare. Questo è un errore. Perché:
1. Come ti hanno già detto ti salvi dati corrotti. L'input inserito dall'utente non corrisponderà a quello salvato nel database, e questo non deve succedere. Piuttosto, se a livello di applicazione c'è qualcosa che non vuoi salvare, lancia una eccezione ed informa l'utente che quello che ha inserito non va bene.
2. "Purgando" la stringa prima di salvarla nel database vincoli quei dati ad un solo utilizzo. Ma, oltre che essere stampati a video in una pagina html, potrebbero essere inviati via email, o utilizzati in altre query. Inoltre, cosa succederebbe se ti accorgessi tempo dopo che la funzione con cui vai a filtrare i contenuti manca di qualcosa? Ri-salvi tutti i dati del tuo database secondo il nuovo formato?

Il lavoro di togliere pezzi html, script, parolacce, tutte le parole che iniziano con la lettera "S", o quello che ti pare, lo fai quando vai ad utilizzare quei dati. E lo fai tenendo conto di dove li stai utilizzando: che sia dentro un < p > o come parametro di una querystring di un collegamento ipertestuale, o come stringa js, le strategie da adottare quando le stampi sono diverse.

Se poi questi valori li usi per generare nomi delle tabelle, allora guarda fai prima a far si che i il valore sia fatto solo da lettere e numeri e senza spazi, al limite gli underscore, perchè tutti gli altri caratteri non andrebbero bene.

E non basterebbero comunque. Se dovessi utilizzare parole chiave dovresti limitare il nome della tabella con delle backticks.
dbal\Connection::quoteIdentifier ti mostra una implementazione di come si potrebbe fare, ma cosa ben più rilevante è il commento:

* NOTE: Just because you CAN use quoted identifiers doesn't mean
* you SHOULD use them. In general, they end up causing way more
* problems than they solve.

Ad esempio,

Essenzialmente N clienti hanno N tabelle (pippo_documenti, pluto_documenti, sempronio_documenti) uguali, ma ovviamente sono diversi (i clienti), e non è che siano proprio contenti qualora "mischiassi" i dati.

C'è un motivo per cui non puoi avere una sola tabella chiamata "documenti" con una colonna "cliente"?

Eh... magari... ovviamente i dati forniti dall'utente DEVONO andare a finire nella query

Qualche post fa ti hanno accennato cos'è prepared statement.
Quindi, la risposta a

l'approccio che ho esposto può dare un livello di sicurezza ragionevole anche per un dilettante PHP ?

è un secco no.

Drupal ho scoperto essere un colabrodo ad esempio

Puoi approfondire?